本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

將 Linux WorkSpace 遷移至不同的作業系統

您可以將現有的 Linux WorkSpace 遷移到不同的 Linux 作業系統套件，同時保留使用者的主目錄、檔案和資料。遷移會將根磁碟區 （作業系統） 取代為新的套件，同時保持使用者磁碟區 (/home) 不變。這與重建不同，重建會使用相同的作業系統套件重新整理根磁碟區。

遷移 WorkSpace 功能會自動處理整個程序，包括檔案所有權更正和桌面環境清理。

支援的遷移路徑

下表顯示 Linux WorkSpace 遷移支援的來源和目標作業系統。

Amazon Linux 2 是有效的遷移來源，但不是有效的遷移目標。Amazon Linux 2 已達到end-of-life，無法使用 AL2 套件建立新的 WorkSpaces。

兩個方向都支援 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 整合，這會指派穩定的使用者 IDs。

先決條件

在遷移 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

若要尋找可用的目標套件 IDs：

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 → AVAILABLE（成功時） PENDING 或 ERROR（失敗時）。如果在佈建期間遷移失敗，控制平面會自動還原原始 WorkSpace。

遷移後驗證

遷移完成後，請確認下列事項：

檢查 WorkSpace 狀態

在 AWS 主控台或透過 CLI 確認 WorkSpace 處於 AVAILABLE 狀態。

驗證使用者登入

讓使用者登入 WorkSpace 並確認桌面負載正確。

檢查遷移日誌

對於 AL2 遷移，請檢閱遷移日誌，以取得變更內容的詳細資訊：

cat ~/workspace-migration-log-*/user-id-migration.txt

此日誌顯示新舊使用者 IDs、每個階段中變更的檔案數量，以及時間戳記。

檢查階段 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 磁碟區中。中的所有檔案在轉換後/home/username仍然存在，包括文件、SSH 金鑰、殼層組態和應用程式資料。

從 Amazon Linux 2 遷移

從 Amazon Linux 2 遷移涉及自動處理的其他步驟。本節說明發生的情況和原因。

為什麼 AL2 遷移不同

Amazon Linux 2 使用 Winbind 進行 Active Directory 整合，而所有較新的 Linux 發行版本 (Ubuntu、RHEL、Rocky) 則使用 SSSD。這兩個系統會將不同的 POSIX 使用者 IDs 指派給相同的 Active Directory 使用者：

遷移後，使用者主目錄中的所有檔案都是舊的 Winbind UID 所擁有。在更正擁有權以符合新的 SSSD UID 之前，使用者無法存取自己的檔案。

此外，Amazon Linux 2 使用 MATE 桌面環境 (GNOME 2)，而較新的發行版本則使用 GNOME 3.x。MATE 組態檔案與 GNOME 3.x 衝突，必須清理以確保桌面正常運作。

兩階段擁有權校正

為了避免佈建逾時，所有權更正分為兩個階段。

階段 1 （佈建期間）

修正立即登入所需的桌面關鍵檔案擁有權：

無論主目錄大小總計為何，階段 1 都會快速完成，確保佈建不會因為大型主目錄而失敗。

階段 2 （背景，重新啟動後）

修正所有剩餘檔案的擁有權：

桌面環境清除

從 AL2 遷移期間，下列 MATE 桌面組態檔案會移至遷移日誌 () 內的備份目錄~/workspace-migration-log-YYYYMMDD/removed-configuration/：

這些檔案不會刪除 - 它們會移至備份目錄，並在需要時可以復原。清除後，桌面會以預設的 GNOME 3.x 外觀載入。

SELinux 內容還原

當遷移目標為 RHEL 或 Rocky Linux 時，無論來源作業系統為何，SELinux 安全內容一律會還原至整個使用者主目錄 (/home/username)。這適用於以啟用 SELinux 的分佈為目標的所有遷移路徑，包括：

在所有情況下，內容還原可確保檔案具有適用於目標分佈 SELinux 政策的正確安全標籤。

內容還原會分兩個階段執行，符合所有權更正：

RFC 2307 主目錄自動更正

Active Directory 支援 RFC 2307 屬性 （也稱為「Unix 屬性」)，可讓管理員指定 POSIX 使用者屬性，包括主目錄路徑 (unixHomeDirectory)。SSSD 會遵守此屬性，而 AL2 上的 Winbind 會忽略它並一律使用 /home/username。

從 AL2 遷移至 SSSD 型分佈時，AD 使用者物件可能已unixHomeDirectory設定為不同的路徑 （例如 /home/CORP/jsmith)。在這種情況下，SSSD 會將使用者的主目錄解析為 AD 指定的路徑。由於使用者的實際資料/home/username位於 AL2 時代的 ，因此磁碟區上不存在 AD 指定的路徑。

遷移系統會自動偵測此情況：

此校正為永久性 — 在重新啟動和未來的 SSSD 重新啟動sssd.conf時override_homedir，設定會保留在 中。

遷移後啟用 RFC 2307 主目錄路徑

如果遷移已自動更正 RFC 2307 主目錄路徑，而且您希望 SSSD 在未來遵守 AD unixHomeDirectory 屬性，您可以反轉覆寫。這是進階組態變更，只有在您了解影響時才應執行。

若要還原 RFC 2307 主目錄路徑：

步驟 1：判斷 AD 指定的主目錄路徑

# Query the AD unixHomeDirectory attribute
ldapsearch -H ldap://your-dc.example.com -b "dc=example,dc=com" \
    "(sAMAccountName=jsmith)" unixHomeDirectory

步驟 2：將使用者的資料移至 AD 指定的路徑

sudo mkdir -p /home/CORP
sudo mv /home/jsmith /home/CORP/jsmith

步驟 3：從 /etc/sssd/sssd.conf 移除 override_homedir 設定

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 衍生的穩定使用者 IDs。使用者的檔案在整個遷移過程中會保留正確的擁有權。

此類別中的常見遷移路徑包括：

對於遷移至 RHEL 或 Rocky Linux 目標，SELinux 內容還原一律執行，以確保檔案具有適用於目標分發 SELinux 政策的正確安全標籤。無論來源分佈為何，這都適用。對於已有正確標籤的檔案，還原是無操作。

使用者保留的項目和變更項目

保留的內容

有哪些變更

自動停止和永遠開啟的 WorkSpaces

自動停止 WorkSpaces

對於使用自動停止設定的 WorkSpaces （閒置逾時後休眠）：

永遠在線的 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 {} +

日誌檔案位置