本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 将 Linux 迁移 WorkSpace 到其他操作系统
您可以将现有 Linux 迁移 WorkSpace 到不同的 Linux 操作系统包，同时保留用户的主目录、文件和数据。迁移将根卷（操作系统）替换为新的捆绑包，同时保持用户卷 (`/home`) 不变。这与重建不同，后者使用相同的操作系统捆绑包刷新根卷。
迁移 WorkSpace 功能会自动处理整个过程，包括文件所有权更正和需要时清理桌面环境。
**Topics**
+ [支持的迁移路径](#linux-migration-paths)
+ [先决条件](#linux-migration-prerequisites)
+ [如何迁移 WorkSpace](#linux-migration-how-to)
+ [Post-migration 验证](#linux-migration-verification)
+ [迁移过程中会发生什么](#linux-migration-during)
+ [从亚马逊 Linux 迁移 2](#linux-migration-from-al2)
+ [在现代发行版之间迁移](#linux-migration-modern-distros)
+ [用户保留的内容和更改的内容](#linux-migration-preserved)
+ [Auto-stop 而且永远在线 WorkSpaces](#linux-migration-autostop-alwayson)
+ [已知限制条件](#linux-migration-limitations)
+ [问题排查](#linux-migration-troubleshooting)
## 支持的迁移路径
下表显示了 Linux WorkSpace 迁移支持的源操作系统和目标操作系统。
| 源操作系统 | Ubuntu 22.04 | Ubuntu 22.04 显卡 | Ubuntu 24.04 | RHEL 8 | RHEL 9 | Rocky 8 | Rocky 9 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 亚马逊 Linux 2 (PCoIP) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 亚马逊 Linux 2 (WSP) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Ubuntu 22.04 | — | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Ubuntu 22.04 显卡 | ✓ | — | ✓ | ✓ | ✓ | ✓ | ✓ |
| Ubuntu 24.04 | ✓ | ✓ | — | ✓ | ✓ | ✓ | ✓ |
| RHEL 8 | ✓ | ✓ | ✓ | — | ✓ | ✓ | ✓ |
| RHEL 9 | ✓ | ✓ | ✓ | ✓ | — | ✓ | ✓ |
| Rocky 8 | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ |
| Rocky 9 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — |
**Amazon Linux 2** 是一个有效的迁移源，但不是有效的迁移目标。Amazon Linux 2 的使用寿命已到期， WorkSpaces 无法使用 AL2 捆绑包创建新的捆绑包。
双向支持 Ubuntu、RHEL 和 Rocky Linux 之间的所有迁移路径。你可以升级（例如，RHEL 8 → RHEL 9）或降级（例如，Ubuntu 24.04 → Ubuntu 22.04）。你也可以跨分发系列（例如 Rocky 9 → Ubuntu 24.04 或 RHEL 9 → Rocky 8）进行迁移。唯一的限制是您不能将一个迁移 WorkSpace 到它已经使用的同一个捆绑包。
从 Amazon Linux 2 迁移需要自动更正用户 ID 所有权并清理桌面环境。所有其他发行版（Ubuntu、RHEL、Rocky）之间的迁移不需要更正所有权，因为这些发行版都使用SSSD进行Active Directory集成，从而分配稳定的用户ID。
## 先决条件
在迁移 Linux 之前 WorkSpace，请验证以下各项：
+ **WorkSpace 州** — WorkSpace 必须处于`AVAILABLE`状态。您无法迁移 WorkSpace 正在启动、停止或处于错误状态的。
+ **没有 Active Directory 森林信任** — WorkSpace 的目录不得配置森林信任关系。SSSD 被所有现代 Linux 发行版用于 Active Directory 集成，但不支持 Forest Trust。如果配置了 Forest Trust，则在置备期间迁移将失败。
+ **足够的 EBS 存储空间** — WorkSpace 必须有足够的 EBS 存储空间才能进行迁移操作。
## 如何迁移 WorkSpace
### 使用 AWS 管理控制台
1. 打开 Amazon WorkSpaces 控制台，网址为[https://console.aws.amazon.com/workspaces/](https://console.aws.amazon.com/workspaces/)。
1. 在导航窗格中，请选择 **WorkSpaces**。
1. 选择 WorkSpace 要迁移的。
1. 选择**操作**，然后选择**迁移 WorkSpace**。
1. 选择目标操作系统捆绑包。
1. 选择 **Migrate**。
### 使用 AWS CLI
使用`migrate-workspace`命令将 a 迁移 WorkSpace 到其他捆绑包：
```
aws workspaces migrate-workspace \
--source-workspace-id ws-1234567890abcdef0 \
--bundle-id wsb-jttwgmx20 \
--region us-east-1
```
要查找可用的目标捆绑包 ID，请执行以下操作：
```
aws workspaces describe-workspace-bundles \
--query 'Bundles[?contains(Name, `Ubuntu`) || contains(Name, `Rocky`) || contains(Name, `RHEL`)].{Name:Name,BundleId:BundleId}' \
--output table
```
### 监控迁移状态
迁移通常需要 20 到 30 分钟。监控 WorkSpace状态：
```
aws workspaces describe-workspaces \
--workspace-ids ws-1234567890abcdef0 \
--query 'Workspaces[0].State' \
--output text
```
通过以下状态进行 WorkSpace 过渡：`AVAILABLE``PENDING`→`AVAILABLE`（成功时）或`ERROR`（失败时）。如果在置备期间迁移失败，控制平面会自动恢复原始 WorkSpace版本。
## Post-migration 验证
迁移完成后，请验证以下各项：
**查看 WorkSpace 状态**
在 WorkSpace AWS 控制台中或通过 CLI 确认`AVAILABLE`处于状态。
**验证用户登录**
让用户登录 WorkSpace 并确认桌面已正确加载。
**查看迁移日志**
对于 AL2 迁移，请查看迁移日志，了解有关更改内容的详细信息：
```
cat ~/workspace-migration-log-*/user-id-migration.txt
```
此日志显示新旧用户 ID、每个阶段更改的文件数以及时间戳。
**检查第 2 阶段的状态**
要验证后台迁移是否已完成，请执行以下操作：
```
# Check if the Phase 2 service is still running
systemctl is-active ws-migrate-phase2.service 2>/dev/null
# "inactive" or "not found" means Phase 2 has completed
# "activating" means Phase 2 is still running (Type=simple service)
```
## 迁移过程中会发生什么
启动迁移时，将执行以下步骤：
1. 用户卷 (`/home`) 已与现有卷分离 WorkSpace。
1. 现有的已 WorkSpace 处置。
1. 从目标操作系统捆绑包中创建了一个新 WorkSpace 的。
1. 用户卷已重新连接到新的音量 WorkSpace 。`/home`
1. 新配置完 WorkSpace 毕：网络配置完毕，实例加入 Active Directory，并设置用户的主目录。
1. 如果从 Amazon Linux 2 迁移，则会更正文件所有权并清理旧桌面配置（参见[从亚马逊 Linux 迁移 2](#linux-migration-from-al2)）。
1. 将 WorkSpace 重新启动并可供用户登录。
用户的主目录存储在单独的 EBS 卷上，该卷在整个迁移过程中一直保留。过渡中的`/home/{{username}}`所有文件，包括文档、SSH 密钥、shell 配置和应用程序数据。
## 从亚马逊 Linux 迁移 2
从 Amazon Linux 2 迁移涉及自动处理的其他步骤。本节解释了会发生什么以及为什么。
### 为什么 AL2 迁移与众不同
**亚马逊 Linux 2 使用 **Winbind 进行** Active Directory 集成，而所有较新的 Linux 发行版（Ubuntu、RHEL、Rocky）都使用 SSSD。**这两个系统为同一 Active Directory 用户分配不同的 POSIX 用户 ID：
+ **Winbind** (AL2)：使用不可预测的算法方案（例如 UID 1000）分配用户 ID。
+ **SSSD**（现代发行版）：分配源自 Active Directory SID 的稳定用户 ID（例如，UID 1285401133）。
迁移后，用户主目录中的所有文件都归旧的 Winbind UID 所有。在更正所有权以匹配新的 SSSD UID 之前，用户无法访问自己的文件。
此外，亚马逊 Linux 2 使用 **MATE** 桌面环境 (GNOME 2)，而较新的发行版使用 **GNOME 3.** x。MATE 配置文件与 GNOME 3.x 冲突，必须对其进行清理才能确保桌面正常运行。
### Two-phase 所有权更正
为避免配置超时，所有权更正分为两个阶段。
**第 1 阶段（置备期间）**
修复了立即登录所需的桌面关键文件的所有权：
+ 主目录本身
+ SSH 密钥 (`~/.ssh/`)
+ 桌面配置 (`~/.config/`)
+ 外壳型材 (`.bashrc`、`.bash_profile`、`.profile`)
+ 任何没有世界读取权限的顶级文件或目录
无论主目录的总大小如何，第 1 阶段都会快速完成，从而确保配置不会因为主目录过大而失败。
**第 2 阶段（后台，重启后）**
修复了所有剩余文件的所有权：
+ 启动时作为 systemd 服务 (`ws-migrate-phase2.service`) 运行
+ 如果 SSSD 在启动时尚未准备就绪，则重试用户解析最多 10 分钟 — 如果解析超时，服务将保持启用状态并在下次启动时重试
+ 使用空闲 I/O 优先级和最低的 CPU 优先级 — 不会影响用户体验
+ 第 2 阶段运行时，用户可以登录并正常工作
+ 大型目录（超过 1000 万个文件）的所有权修复将继续在后台完成
+ Self-removes 成功完成后的 systemd 服务文件
### 桌面环境清理
从 AL2 迁移期间，以下 MATE 桌面配置文件将移至迁移日志 (`~/workspace-migration-log-YYYYMMDD/removed-configuration/`) 内的备份目录：
+ `~/.config/dconf/user`— MATE-specific dconf 数据库
+ `~/.gconf/`— 旧版 gConf 目录
+ `~/.config/mate-session/`— MATE 会话配置
+ `~/.config/mate-panel/`— MATE 面板配置
+ `~/.local/share/mate-panel/`— MATE 面板应用程序数据
+ `~/.config/pluma/`— MATE 文本编辑器设置
+ `~/.config/caja/`— MATE 文件管理器配置
+ `~/.config/marco/`— MATE 窗口管理器设置
+ `~/.config/gtk-2.0/`，`~/.config/gtk-3.0/`— GTK 主题配置
+ `~/.local/share/recently-used.xbel`— 最近文件列表
这些文件不会被删除，而是移动到备份目录中，需要时可以恢复。清理完成后，桌面将以默认的 GNOME 3.x 外观加载。
### SELinux 上下文恢复
当迁移目标是 RHEL 或 Rocky Linux 时，无论源操作系统如何，SELinux 安全上下文始终会在整个用户主目录 (`/home/{{username}}`) 中恢复。这适用于所有以 SELinux-enabled 分布为目标的迁移路径，包括：
+ 从非 SELinux 来源（Ubuntu、AL2）迁移，那里的文件完全没有 SELinux 标签。
+ SELinux-enabled 分布之间的迁移（例如，RHEL 8 → RHEL 9、Rocky 8 → Rocky 9 或 RHEL 9 → Rocky 9）。在主要版本之间，SELinux 政策版本和文件上下文定义可能会发生变化。
在所有情况下，上下文恢复都可确保文件具有目标发行版的 SELinux 策略的正确安全标签。
上下文恢复分两个阶段运行，与所有权更正相匹配：
+ **阶段 1**：在置备期间恢复关键路径 (`~/.ssh/`,`~/.config/`) 上的上下文。
+ **第 2 阶段**：重启后在后台恢复整个主目录的上下文。
### RFC 2307 主目录自动更正
Active Directory 支持 RFC 2307 属性（也称为 “Unix 属性”），这些属性允许管理员指定 POSIX 用户属性，包括主目录路径 ()。`unixHomeDirectory`SSSD 尊重这个属性，而 AL2 上的 Winbind 却忽略了它并一直使用。`/home/{{username}}`
从 AL2 迁移到 SSSD-based 分配时，AD 用户对象可能已`unixHomeDirectory`设置为不同的路径（例如，`/home/CORP/jsmith`）。在这种情况下，SSSD 会将用户的主目录解析为该 AD-specified 路径。由于用户的实际数据存在于 `/home/{{username}}` AL2 时代，因此卷上不存在 AD-specified 路径。
迁移系统会自动检测到这种情况：
1. 配置后，SSSD 会将用户的主目录解析为路径。 AD-specified
1. 迁移系统会检查用户卷上是否存在此路径。
1. 如果 AD-specified 路径不存在但`/home/{{username}}`存在，则系统会将其识别为 RFC 2307 路径不匹配。
1. 系统`override_homedir=/home/%u`直接设置`/etc/sssd/sssd.conf`（在所有域部分）并重新启动 SSSD。
1. SSSD 重新启动后，用户的主目录将解析为数据`/home/{{username}}`实际所在的位置。
1. 迁移通常会根据现有数据进行。
此更正是永久性的 — 该`override_homedir`设置`sssd.conf`在重新启动和 future SSSD 重启后仍然存在。
### 迁移后启用 RFC 2307 主目录路径
如果迁移自动更正了 RFC 2307 主目录路径，并且您希望 SSSD 今后尊重 AD `unixHomeDirectory` 属性，则可以撤消覆盖。这是一项高级配置更改，只有在您了解其含义后才应执行。
**警告**
移除覆盖后，SSSD 将使用 AD-specified 主目录路径。在移除覆盖之前，必须将用户的数据移动到该路径，否则用户将获得一个空的主目录。
要恢复 RFC 2307 主目录路径，请执行以下操作：
**步骤 1：确定 AD-specified 主目录路径**
```
# Query the AD unixHomeDirectory attribute
ldapsearch -H ldap://your-dc.example.com -b "dc=example,dc=com" \
"(sAMAccountName=jsmith)" unixHomeDirectory
```
**步骤 2：将用户的数据移动到 AD-specified路径中**
```
sudo mkdir -p /home/CORP
sudo mv /home/jsmith /home/CORP/jsmith
```
**第 3 步：从 //sssd.conf 中删除 override\_homedir 设置 etc/sssd**
```
sudo sed -i '/^override_homedir/d' /etc/sssd/sssd.conf
```
**步骤 4：重启 SSSD**
```
sudo systemctl restart sssd
```
**步骤 5：验证主目录解析是否正确**
```
getent passwd jsmith
# Should show /home/CORP/jsmith as the home directory
```
**重要**
移除覆盖后，future 的 WorkSpace 重建和迁移将使用该路径。 AD-specified 在下次重建或迁移之前，请确保数据位于正确的位置。
### 用户通知
迁移系统使用两种通知机制让用户随时了解情况：
1. **第 2 阶段 systemd 服务通知** — 如果用户在第 2 阶段开始或完成时连接到桌面，则他们会直接看到来自该服务的通知：
+ **在第 2 阶段开始：**“在后台完成文件迁移。您可以继续正常工作。在迁移完成之前，有些文件可能仍然无法访问。”
+ **第 2 阶段完成时：**“文件迁移成功完成。现在，所有文件都应该拥有正确的所有权。有关详细信息，请参阅 \~/workspace-migration-log-\*。”
1. **XDG 自动启动登录通知**-自动启动条目 (`~/.config/autostart/ws-migration-notify.desktop`) 在迁移后首次`/usr/lib/skylight/check-migration-status`登录时运行。这可以处理用户在第 2 阶段仍在运行时或已经完成之后进行连接的情况：
+ **如果第 2 阶段仍在运行：**“文件迁移正在后台运行。您可以继续正常工作。在迁移完成之前，有些文件可能仍然无法访问。”
+ **如果第 2 阶段已完成：**“文件迁移已成功完成。现在，所有文件都应该拥有正确的所有权。有关详细信息，请参阅 \~/workspace-migration-log-\*。”
在显示完成通知后，自动启动条目将被删除，因此它不会在后续登录时运行。
如果用户未连接（例如，尚未访问过的自动停止） WorkSpace ，则第 2 阶段将静默运行，不会出现错误。
## 在现代发行版之间迁移
在 Ubuntu、RHEL 和 Rocky Linux 发行版之间迁移不需要更正用户 ID 所有权。所有这些发行版都使用 SSSD 进行 Active Directory 集成，它会分配从 AD SID 派生的稳定用户 ID。在整个迁移过程中，用户的文件保持正确的所有权。
此类别中的常见迁移路径包括：
+ **Cross-family:** Ubuntu 22.04 ↔ RHEL，Ubuntu 22.04 ↔ R 8/9 ocky，RHEL ↔ Rocky 8/9
+ **版本升级：**Ubuntu 22.04 → Ubuntu 24.04、RHEL 8 → RHEL 9、Rocky 8 → Rocky 8 → Rocky 9
+ **显卡捆绑包：**任何来源 → Ubuntu 22.04 Graphics。Ubuntu Graphics WorkSpaces 也可以迁移到任何非图形目标。
对于迁移到 RHEL 或 Rocky Linux 目标，SELinux 上下文恢复始终运行，以确保文件具有目标发行版的 SELinux 策略的正确安全标签。无论源分布如何，这都适用。对于已经有正确标签的文件，恢复是不行的。
## 用户保留的内容和更改的内容
### 保存了什么
+ 主目录中的所有文件（“文档”、“下载”、“桌面” 等）
+ SSH 密钥和配置 (`~/.ssh/`)
+ 外壳配置 (`.bashrc`、`.profile`、`.bash_profile`)
+ 浏览器书签和个人资料（Firefox、Chrome）
+ Application-specific 数据和配置（AL2 迁移时的 MATE 桌面组件除外）
### 发生了什么变化
+ 桌面环境重置为目标发行版上的默认 GNOME 3.x 外观。
+ 旧版 MATE 桌面首选项已删除并备份（仅限 AL2 迁移）。
+ 桌面图标和面板自定义设置重置为默认值。
+ 根卷上已安装的应用程序将替换为目标捆绑包的默认应用程序。用户在其主目录中安装的应用程序将被保留。
## Auto-stop 而且永远在线 WorkSpaces
### Auto-stop WorkSpaces
对于 WorkSpaces 配置了自动停止（空闲超时后进入休眠状态）：
1. 迁移完成并 WorkSpace 重新启动。
1. 第 2 阶段的后台服务在启动时启动。如果 SSSD 尚未准备就绪，则该服务会重试用户解析最多 10 分钟，然后再继续。
1. 如果用户未在空闲超时时间（通常为 1 小时）内连接，则第 2 阶段将在后台静默运行。
1. 对于典型的工作负载（少于 100,000 个文件），第 2 阶段将在空闲超时内完成。
1. 第 2 阶段完成后 WorkSpace 进入休眠状态。
1. 当用户下次连接时，迁移已经完成，并且不会显示任何通知。
### Always-on WorkSpaces
对于永远在线 WorkSpaces：
1. 迁移完成并 WorkSpace 重新启动。
1. 第 2 阶段的后台服务在启动时启动并运行直至完成。
1. 用户可以随时连接并正常工作 — 第 2 阶段以空闲优先级运行，不会影响性能。
## 已知限制条件
+ **Active Directory 森林信任：**SSSD 不支持森林信任关系。 WorkSpaces 在配置了森林信任的目录中无法迁移。
+ **Amazon Linux 2 作为目标：**AL2 已达到使用寿命终止期，不是有效的迁移目标。您只能*从* AL2 迁移，不能迁移*到* AL2。
+ **不回滚：**已完成的迁移无法回滚到以前的操作系统。如果需要返回以前的操作系统，则必须启动新的迁移（AL2 除外，它不是有效的目标）。
+ **MATE 桌面自定义：**从 AL2 迁移时，MATE 桌面首选项将被删除。它们已备份到 GNOME 3.x 桌面，`~/workspace-migration-log-YYYYMMDD/removed-configuration/`但无法自动应用于 GNOME 3.x 桌面。
+ **大型主目录：**对于包含数百万个文件的主目录，第 2 阶段的后台所有权更正可能需要几个小时。在此期间，用户可以正常工作，但在第 2 阶段完成之前，某些文件的所有权可能不正确。
+ **文件共享：**如果用户在其主目录上设置了文件共享（例如 Samba 共享），则 AL2 迁移期间的所有权更改可能会影响共享权限。迁移后可能需要重新建立文件共享配置。
+ **RFC 2307 覆盖：**如果迁移自动更正了 RFC 2307 主目录路径不匹配的情况，则会通过 in 重写 AD 属性。`unixHomeDirectory` `override_homedir` `sssd.conf`看看你[迁移后启用 RFC 2307 主目录路径](#linux-migration-al2-rfc2307-reverse)是否希望 SSSD 遵守这 AD-specified 条道路。
## 问题排查
### 置备期间迁移失败
如果迁移失败并且 WorkSpace 恢复到`ERROR`状态，则控制平面会自动尝试恢复原始状态 WorkSpace。查看配置日志：
```
# Connect to the WorkSpace (if accessible) and check the domain-join log
sudo cat /var/log/skylight/domain-join.log
```
常见原因：
+ **已配置森林信任：**SSSD 无法使用森林信任加入域。迁移前请移除森林信任。
+ **AD 连接问题：** WorkSpace 无法访问域控制器。验证 VPC 网络和安全组规则。
+ **DNS 解析失败：** WorkSpace 无法解析 AD 域。验证 DNS 配置。
### 迁移后用户无法登录
+ 验证是否 WorkSpace 处于`AVAILABLE`状态。
+ 检查域名加入是否成功完成：`sudo cat /var/lib/skylight/domain-join-status`应包含`true`。
+ 验证是否可以解析用户：`id {{username}}`应返回用户的 UID 和群组。
+ 检查 SSSD 状态：`sudo sssctl domain-status {{domain}}`应显示`Online status: Online`。
### 桌面出现损坏或主题错误
从 AL2 迁移并且某些 MATE 配置文件未清理时，通常会发生这种情况。要将桌面重置为默认值，请执行以下操作：
```
# Remove remaining desktop configuration
rm -rf ~/.config/dconf/user
rm -rf ~/.gconf
# Log out and log back in
```
### 迁移后文件的所有权错误
如果在 AL2 迁移后无法访问主目录中的文件，则第 2 阶段可能仍在运行：
```
# Check Phase 2 status
systemctl is-active ws-migrate-phase2.service 2>/dev/null
# Check the migration log for progress
cat ~/workspace-migration-log-*/user-id-migration.txt
```
如果第 2 阶段已完成，但某些文件的所有权仍然不正确，则可以手动修复它们：
```
# Find files with the old UID and change ownership
sudo find /home/{{username}} -uid {{old-uid}} -exec chown {{username}} {} +
sudo find /home/{{username}} -gid {{old-gid}} -exec chgrp {{username}} {} +
```
### 日志文件位置
| Log | 位置 | 内容 |
| --- | --- | --- |
| 域加入日志 | /var/log/skylight/domain-join.log | 完整的配置工作流程，包括迁移第 1 阶段 |
| 迁移摘要 | \~/workspace-migration-log-YYYYMMDD/user-id-migration.txt | Old/new 第 1 阶段和第 2 阶段的 UID、文件计数、时间戳 |
| Backed-up MATE 配置 | \~/workspace-migration-log-YYYYMMDD/removed-configuration/ | AL2 迁移期间移除了 MATE 桌面文件 |
| 第 1 阶段文件列表 | \~/workspace-migration-log-YYYYMMDD/phase1-processed-files.txt | 第 1 阶段处理的文件（第 2 阶段使用该文件跳过重复文件） |