将 Linux 迁移 WorkSpace 到其他操作系统

您可以将现有 Linux 迁移 WorkSpace 到不同的 Linux 操作系统捆绑包，同时保留用户的主目录、文件和数据。迁移将根卷（操作系统）替换为新的捆绑包，同时保持用户卷 (/home) 不变。这与重建不同，后者使用相同的操作系统捆绑包刷新根卷。

迁移 WorkSpace 功能会自动处理整个过程，包括文件所有权更正和需要时清理桌面环境。

支持的迁移路径

下表显示了 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/。

2. 在导航窗格中，请选择 WorkSpaces。

3. 选择 WorkSpace 要迁移的。

4. 选择操作，然后选择迁移 WorkSpace。

5. 选择目标操作系统捆绑包。

6. 选择 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 过渡：AVAILABLEPENDING→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。

2. 现有的已 WorkSpace 处置。

3. 从目标操作系统捆绑包中创建了一个新 WorkSpace 的。

4. 用户卷已重新连接到新的音量 WorkSpace 。/home

5. 新配置完 WorkSpace 毕：网络配置完毕，实例加入 Active Directory，并设置用户的主目录。

6. 如果从 Amazon Linux 2 迁移，则会更正文件所有权并清理旧桌面配置（参见从亚马逊 Linux 迁移 2）。

7. 将 WorkSpace 重新启动并可供用户登录。

用户的主目录存储在单独的 EBS 卷上，该卷在整个迁移过程中一直保留。过渡中的/home/username所有文件，包括文档、SSH 密钥、外壳配置和应用程序数据。

从亚马逊 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 用户属性，包括主目录路径 ()。unixHomeDirectorySSSD 尊重这个属性，而 AL2 上的 Winbind 却忽略了它并一直使用。/home/username

从 AL2 迁移到 SSSD-based 发行版时，如果 AD 用户对象已unixHomeDirectory设置为其他路径（例如/home/CORP/jsmith），SSSD 会将用户的主目录解析为该路径。 AD-specified 由于用户的实际数据存在于 /home/username AL2 时代，因此卷上不存在 AD-specified 路径。

迁移系统会自动检测到这种情况：

1. 配置后，SSSD 会将用户的主目录解析为路径。 AD-specified

2. 迁移系统会检查用户卷上是否存在此路径。

3. 如果 AD-specified 路径不存在但/home/username存在，则系统会将其识别为 RFC 2307 路径不匹配。

4. 系统override_homedir=/home/%u直接在/etc/sssd/sssd.conf（在所有域区域中）进行设置并重新启动 SSSD。

5. SSSD 重新启动后，用户的主目录将解析为数据/home/username实际所在的位置。

6. 迁移通常会根据现有数据进行。

此更正是永久性的 — 该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-*。”

2. 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 重新启动。

2. 第 2 阶段的后台服务在启动时启动。如果 SSSD 尚未准备就绪，则该服务会重试用户解析最多 10 分钟，然后再继续。

3. 如果用户未在空闲超时时间（通常为 1 小时）内连接，则第 2 阶段将在后台静默运行。

4. 对于典型的工作负载（少于 100,000 个文件），第 2 阶段将在空闲超时内完成。

5. 第 2 阶段完成后 WorkSpace 进入休眠状态。

6. 当用户下次连接时，迁移已经完成，并且不会显示任何通知。

Always-on WorkSpaces

对于永远在线 WorkSpaces：

1. 迁移完成并 WorkSpace 重新启动。

2. 第 2 阶段的后台服务在启动时启动并运行直至完成。

3. 用户可以随时连接并正常工作 — 第 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 主目录路径是否希望 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 阶段使用该文件跳过重复文件）