本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

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

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

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

支持的迁移路径

下表显示了 Linux WorkSpace 迁移支持的源和目标操作系统。

Amazon Linux 2 是有效的迁移源，但不是有效的迁移目标。亚马逊 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

使用 AWS 管理控制台

使用 AWS CLI

使用migrate-workspace命令将迁移 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)

迁移过程中会发生什么

启动迁移时，将执行以下步骤：

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

从亚马逊 Linux 2 迁移

从 Amazon Linux 2 迁移涉及自动处理的额外步骤。本节解释了会发生什么以及为什么。

为什么 AL2 迁移与众不同

亚马逊 Linux 2 使用 Winbind 进行活动目录集成，而所有较新的 Linux 发行版（Ubuntu、RHEL、Rocky）都使用 SSSD。这两个系统为同一 Active Directory 用户分配不同的 POSIX 用户 ID：

迁移后，用户主目录中的所有文件均归旧的 Winbind UID 所有。在更正所有权以匹配新的 SSSD UID 之前，用户无法访问自己的文件。

此外，亚马逊 Linux 2 使用 MATE 桌面环境 (GNOME 2)，而较新的发行版使用 GNOME 3.x。MATE 配置文件与 GNOME 3.x 冲突，必须进行清理以确保桌面正常运行。

Two-phase 所有权更正

为避免配置超时，所有权更正分为两个阶段。

第 1 阶段（配置期间）

修复了立即登录所需的桌面关键文件的所有权：

无论主目录的总大小如何，第 1 阶段都会快速完成，从而确保配置不会因主目录过大而失败。

第 2 阶段（后台，重启后）

修复所有剩余文件的所有权：

桌面环境清理

在从 AL2 迁移期间，以下 MATE 桌面配置文件将移至迁移日志中的备份目录 (~/workspace-migration-log-YYYYMMDD/removed-configuration/)：

这些文件不会被删除——它们被移到备份目录中，需要时可以恢复。清理后，桌面加载时会显示默认的 GNOME 3.x 外观。

SELinux 上下文恢复

当迁移目标是 RHEL 或 Rocky Linux 时，无论源操作系统如何，SELinux 安全上下文都将始终恢复在整个用户主目录 (/home/username) 上。这适用于所有以 SELinux-enabled 发行版为目标的迁移路径，包括：

在所有情况下，上下文恢复都可确保文件具有目标发行版的 SELinux 政策的正确安全标签。

上下文恢复分两个阶段运行，与所有权更正相匹配：

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 路径。

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

此更正是永久性的，该override_homedir设置sssd.conf在重新启动和将来的 SSSD 重启后仍然有效。

迁移后启用 RFC 2307 主目录路径

如果迁移自动更正了 RFC 2307 主目录路径，并且您希望 SSSD 今后遵守 AD unixHomeDirectory 属性，则可以撤消重写。这是一项高级配置更改，只有在您了解其含义后才能执行。

要恢复 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

用户通知

迁移系统使用两种通知机制来让用户随时了解情况：

如果用户未连接（例如，尚未访问的自动停机） WorkSpace ，第 2 阶段将静默运行，不会出现错误。

在现代发行版之间迁移

在 Ubuntu、RHEL 和 Rocky Linux 发行版之间迁移不需要更正用户 ID 所有权。所有这些发行版都使用 SSSD 进行 Active Directory 集成，它分配源自 AD SID 的稳定用户 ID。在整个迁移过程中，用户的文件保留了正确的所有权。

此类别中的常见迁移路径包括：

对于迁移到 RHEL 或 Rocky Linux 目标，SELinux 上下文还原将始终运行，以确保文件具有符合目标发行版的 SELinux 政策的正确安全标签。无论源发行版如何，这都适用。对于已经有正确标签的文件，恢复是行不通的。

用户保留了哪些内容和更改了什么

保存了什么

发生了什么变化

Auto-stop 而且永远在线 WorkSpaces

Auto-stop WorkSpaces

对于 WorkSpaces 配置为自动停止（空闲超时后进入休眠状态）：

Always-on WorkSpaces

为了永远在线 WorkSpaces：

已知限制条件

问题排查

配置期间迁移失败

如果迁移失败并 WorkSpace 恢复ERROR状态，则控制平面会自动尝试恢复原始文件 WorkSpace。检查配置日志：

# Connect to the WorkSpace (if accessible) and check the domain-join log
sudo cat /var/log/skylight/domain-join.log

常见原因：

迁移后用户无法登录

桌面出现故障或主题错误

这通常发生在从 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 {} +

日志文件位置