共用方式為


桌面檔案在虛擬世界中部署 Windows

Wes Miller

虛擬運算技術比比皆是,如果您還沒利用到它,應該開始採用。虛擬化可降低硬體依存性,它基本上會建立自己的硬體抽象層,可讓您在主機系統之間移動一或多個虛擬系統 (例如 Windows Server 或 Windows 用戶端作業系統)。

不用說,虛擬化與模擬是有差別的,虛擬化並不會模仿虛擬系統的處理器,它只是以虛擬系統可以存取的方式來表示主機系統的資源。也就是說,主機系統對虛擬系統來說是通用的。一般來說,您可以在不同 OEM 所建造的系統間移動虛擬系統,主機的硬體通常無關緊要,但有些地方要特別注意。比方說,如果您將虛擬系統從含有某 CPU 廠商 (例如 AMD) 處理器的硬體移到含有另一個廠商 (例如 Intel) 處理器的硬體,可能會出問題 (要看您採用的虛擬化技術而定)。這是因為虛擬運算技術只會在主機和虛擬系統間來回傳遞資訊,它並不會模擬虛擬系統的特定 CPU (譬如,在舊版 PowerPC 型 Macintosh 上執行的 Microsoft® Virtual PC 就可以這麼做)。

不過,虛擬化倒是會對虛擬系統模擬重要的硬體元件。這大多限於網路、視訊 (一般是不含進階模擬 GPU 且相當有限的裝置) 和大型存放區。這些組合全都是藉著向虛擬系統呈現一或多種軟體模擬的裝置來運作。如果您閱讀我的專欄已經有一段時間,就會注意到這跟 Windows® PE 所因應的是同一份裝置清單。在虛擬化中,這份裝置清單與您讓 Windows 真正辦事所需的裝置類型一樣。除此之外,所有虛擬化技術也都必須模擬 BIOS。雖然它們也可以模擬可延伸韌體介面 (EFI),但是在當今 EFI 作業系統有限的情況下,還是少用為妙,這樣的模擬就足以讓虛擬系統開機。BIOS 和每個裝置都會在軟體中模擬實際的裝置,然後將該裝置呈現給虛擬系統。這表示,它們也像實際裝置一樣需要驅動程式 (並不一定是 Windows 提供的驅動程式)。這個概念很重要,理當謹記在心。

雖然有些虛擬化技術也可以讓 USB (或 USB 2.0) 裝置與其互動,但對於這些技術的細節我在此將不多做著墨。除了那些 USB 裝置需裝有驅動程式 (印表機、USB 無線 NIC 等等) 或特定DirectX® 支援 (大多數虛擬化技術中通常沒有) 之外,您應該不用多做什麼,就可以讓它們順利運作。有一點別忘了,要支援 USB 或其他非模擬的裝置,當然是要看您所採用的虛擬化技術而定。在嘗試將您所採用的虛擬化產品與新裝置搭配使用之前,應確實了解它的限制 (正如我所謂的工欲善其事,必先利其器)。

目前 Windows 上有兩大虛擬化技術廠商:Microsoft 和 VMware (vmware.com),還有一些後起之秀如 Parallels (parallels.com)。

現在,您對虛擬化已經有了初步的了解,接著我將在專欄的其餘的部份討論如何進行設定、如何避開最常見的陷阱,以及如何在您環境中眾多的機器間進行部署。

虛擬部署

部署虛擬系統跟部署實體系統沒什麼太大差別,但是您等一下就會看到,做出區別其實不無道理。

在早期的 Windows NT® 時代,您得透過安裝程式來部署。沒錯,是可以用指令碼來進行,但還是得跑完整個程序。安裝程式一完成,就將該映像複製到多台系統上,這種方法在概念上是蠻便利的,但實際上並不受到支援。

最後,Microsoft 終於決定應該支援磁碟複製或是「複製」的 Windows NT 系統。所以,目前在部署實體系統時可採行的方法,同樣也適用於部署虛擬系統,那就是:Winnt32 (也就是 Windows Vista® 和 Windows Server® 2008 上為 setup.exe);Windows PE (1.x 或 2.x,視您正在部署的用戶端而定,如我之前的專欄中所說明的一樣);遠端安裝服務 (RIS) 或 Windows 部署服務 (WDS);或是 Sysprep (隨 Windows NT 4.0 推出用於部署的系統準備工具),以及您最喜愛的磁碟複製技術 (例如 ImageX)。

當然啦,您只需要在第一次部署特定 OS 時才需要這麼做。之後,只要複製就可以了。但是採用我剛剛提到的這些磁碟複製方法有個問題。

使用 Sysprep

Microsoft 不支援磁碟複製的最初決定主要是由 Windows NT 安全性識別項 (SID) 提出的。所幸,Sysprep 提供一個解決辦法。不過先來看看它要解決的問題。如 support.microsoft.com/kb/314828 中所述,SID 是由 SID 結構修訂編號 (通常是全域唯一識別碼,或稱 GUID) 組成,用來識別個別的 Windows 電腦。此一識別碼接著會被用作為所有本機帳戶識別碼的根項。本機帳戶有其各自的唯一識別碼,稱為相關識別元 (RID)。RID 包括了帳戶識別碼,與 SID 結尾串聯。因此兩者的組合遂成了本機帳戶的識別碼。

讓我們來看看為什麼使用系統管理員 SID S-1-5-21-191058668-193157475-1542849698-500 會有問題。此處的 S-1-5 是一個描述項,用來定義這是一個 SID (SID 的文字表示中一定會有 S),而 1 和 5 則分別表示 Windows NT SID 修訂編號和授權識別碼值 (在此為 Windows Security)。其餘的部分則是真正的 SID,包括 500,代表這是已知的 SID — Windows 系統管理員帳戶。所有 Windows 安裝上預設建立的系統管理員帳戶 (而且無法加以刪除) 都有個以 500 為結尾的 SID。安裝之後新增到 Windows 的本機使用者帳戶則從 1000 開始重覆。

Windows Sysinternals (在我討論 PSTools 的專欄中曾提到,網址是 technetmagazine.com/issues/2007/03/DesktopFiles) 所提供的 PSGetSID,可讓您列舉系統上指定使用者的 SID 或系統的 SID。請參閱 [圖 1],其中的 PSGetSID 輸出顯示我的虛擬系統的 SID 以及我的使用者帳戶 1003 的 SID。

Figure 1 Output of PSGetSID for a virtual system's SID and the SID of user account 1003

Figure 1** Output of PSGetSID for a virtual system's SID and the SID of user account 1003 **(按影像可放大)

由於本機帳戶 RID 是以這個 SID 為基礎,因此當您以磁碟複製系統或直接複製虛擬機器映像時,會發生什麼問題應該顯而易見。因為不變更 SID (這是 Sysprep 的主要工作但不是唯一的工作),您最後得到的是重要元件的副本,這是讓 Windows 系統之所以獨一無二的元件。如果系統 A 和系統 B 具有相同的系統管理員 SID,那麼各系統上的使用者就可以合法地將自己識別為相同的使用者。當向系統 A 驗證時,系統 B 的所有本機帳戶也可以這麼做,反之亦然。更糟的是,這些系統在呈現給 Active Directory® 時也將具有相同的 SID。因此,如果您允許系統 A 向網域資源驗證,但不允許系統 B 這麼做,便會發生衝突。若將 B 設為拒絕,實際上也會拒絕 A。

因此,使用 Sysprep 在系統上重新產生 SID 是很重要的 — 尤其是在虛擬系統的案例下,因為系統映像很容易就可以傳播。您也不該使用協力廠商 SID 變更工具 — 只能使用 Sysprep。Sysprep 是經過 Microsoft 的設計、測試且受到它的支援,可用來準備系統進行複製 (即使是虛擬系統)。請參閱 [圖 2] 看一下在變更系統上的 SID 之前,Sysprep 的模樣。如果您的下一步是要準備系統以進行複製,請確定永遠不要選取 [不重新產生安全性識別元] 選項。

Figure 2 "Don't regenerate security identifiers" should be unchecked when preparing for duplication

Figure 2** "Don't regenerate security identifiers" should be unchecked when preparing for duplication **

除了將 SID 更新成新的識別碼之外,Sysprep 還會修改任何它所知的私人資料存放區,來反映 SID 和電腦名稱,或變更它們的加密以採用新 SID。當中的例子包括排定的工作資料存放區,以及 IIS Metabase 裡面的值 (若有安裝 IIS 的話)。

Sysprep 也會強制刪除系統上的每個 NIC,連帶清除該 NIC 的網路設定資料。因為網路設定在登錄中是掛在 NIC 上,而且與該 NIC 的關係依據的是 NIC 的硬體識別碼 (這在虛擬移向虛擬系統以外的情況下常常可能拆散),所以 Sysprep 也將這個過去被遺棄的資料一併清理掉。

Sysprep 還會清理系統上所有 Active Directory 成員資格的資訊。換句話說,強迫將系統從網域中移除是它的職責之一。這可確保剛收到新 SID 的系統可安全地加入網域。有些 SID 變更公用程式讓您不必將電腦從網域中移除,即可變更它的 SID,但這既不可靠也不安全。如果您真的有必要在屬於網域成員的機器上執行 Sysprep,可以在執行 Sysprep 前將它從網域移除,或是執行 Sysprep 並讓它為您料理這檔事。

還有相關的一點要注意的是,如果您將任何網域控制站 (DC) 虛擬化,則必須複製尚未升級為 DC 且未加入網域而只是獨立伺服器的系統。Windows Server 2003 Small Business Server Edition 則是例外,在此版本中,您無法安全地磁碟複製 DC。若要安全地建立新 DC,您應該為已經準備好加入網域且已升級為 DC 的伺服器建立磁碟映像。Sysprep (除了在 SBS 的特例下,也就是單一樹系/單一伺服器的情況下) 並不知道要怎麼在 DC 上安全地變更 SID。

最後,除了變更 SID 並將電腦從網域移除之外,Sysprep 還會變更電腦名稱。

在製作 (甚或只是複製) 虛擬系統的映像時,說您得執行所有上述的工作看起來可能很吃重。可是這些都是必要的動作 — 尤其是當您在包含其他實體或虛擬系統的網路上、網域中使用這些系統,或是在網路上與它們自己任何其他副本共同使用時。

如果您在複製虛擬系統時不使用 Sysprep,十之八九會碰到幾個明顯的問題 (Active Directory 或其他網路衝突),而且有好些問題可能是您始料未及的。例如,您的虛擬映像將非常容易受到駭客攻擊,因為只要攻擊一個就可以獲得其他幾個的存取權。

驅動程式和硬體抽象層

我之前說過,內含在虛擬映像中的虛擬裝置可能沒有 Windows 的「內建」驅動程式。在部署 (或是當使用 Sysprep 部署磁碟映像) 時,確定您手邊有裝置的驅動程式,因為將虛擬映像從一個存放匯流排驅動程式移到另一個存放匯流排驅動程式就跟使用實體的硬體一樣,很容易發生可怕的 0x0000007B 驅動程式錯誤。NIC 的情況也是如此,雖然大多數的虛擬化產品都尋求提供相當通用的虛擬裝置,您可能還是有需要為它安裝額外的驅動程式。

您也不能忽視那個討厭的硬體抽象層 (HAL)。在理想的情況下,您應建立虛擬機器來支援 Advanced Configuration and Power Interface (ACPI) 多處理器 (請參閱 intel.com/technology/iapc/acpi),如果您的虛擬技術有支援的話。在 HAL 間轉換通常不受到支援 (請參閱 support.microsoft.com/kb/309283 以取得詳細資訊)。然而,有些虛擬化技術— 或者,更重要的是,許多移轉技術 — 都承諾它們可以安全地將非 ACPI 的 Windows 安裝移到 ACPI 安裝,或反之亦然。但事實並非如此,而且若您果真遇到問題,Microsoft 也不支援由此產生的 Windows 安裝。我剛剛提到的支援網頁上所討論的限制也適用於虛擬化的系統。請參閱 [圖 3] 的例子,參考 HAL 在我其中一台虛擬機器上的裝置管理員中看起來的樣子 — 在本例中是使用 ACPI 單一處理器 HAL 執行。請勿與單一處理器相混淆,這個處理器可與其多處理器家族相互交換。

Figure 3 HAL in Device Manager on a virtual machine

Figure 3** HAL in Device Manager on a virtual machine **(按影像可放大)

其他變更

變您所能變並接受您所不能變

當考慮將實體移轉到虛擬時 (反之亦然),您必須記住可變與不可變的事項。您可以變更 Windows 安裝的下列各方面:

  • HAL (但只能從單一處理器變更為多處理器,或反之亦然,只要它們以相同的電源設定為基礎便可)。
  • 大型存放控制器 (這並不容易 — 但大多數的實體移轉至虛擬的解決方案都已經自行嘗試這麼做)。要注意的是,大部分的廠商都提供 IDE 和 SCSI 存放解決方案。部署時請做出明智的選擇,因為移轉的作業並不輕鬆。一般來說,選擇 SCSI 會產生比較可靠的裝置 (這是就大部分廠商 SCSI 裝置模擬實作的情況而言)。
  • 網路控制卡 (雖然在虛擬移轉至虛擬的案例下,這在同一家廠商的技術內通常並無不同)。

您無法變更 Windows 安裝的下列各方面:

  • HAL (除了前文所述使用相同的電源設定時)。您不應假設進行此動作的移轉解決方案會產生穩定或可靠的 Windows 安裝 (而且更重要的是,它並不會受到 Microsoft 支援)。

除了變更 SID 和電腦名稱,您還必須變更某些與您所使用的虛擬運算技術相關的值。您尤其必須變更 MAC 位址 (網路裝置的唯一識別碼)。此外,許多虛擬應用程式也都有自己的唯一識別碼。絕大多數都是將這些存放在自己的電腦設定檔案中,因此您應該要知道如何操控這些項目 (以及維持它們的有效性)。請注意,許多支援 Pre-Boot Execution Environment (PXE) 的虛擬化產品會根據自己的唯一識別碼來輸入 SMBIOS UUID — 這更凸顯了如果您將它加入網域時必須變更這項行為 (或是讓支援的虛擬化軟體為您進行變更);否則可能無法管理 WDS 或 RIS 用戶端系統 (如果 GUID 發生衝突的話)。我用過的大部分虛擬化解決方案在發生 MAC 位址重複的情況下,可能會造成嚴重的網路問題;因此如果您不只是要移動虛擬機器而已,變更 MAC 位址 (如果虛擬化軟體沒有為您變更的話) 是很重要的。

在準備要部署的虛擬系統時,其他必須注意的元件就是連結的磁碟或快照集。根據您的虛擬化解決方案而定,這些元件也可能稱為差異磁碟或其他不同的名稱。但要是您執行 Sysprep 來準備系統,並且有搭配虛擬系統的快照集 (或其他可還原的狀態) 時,為了讓映像在複製時保持安全和可靠,必須摧毀它們。在採用快照集或其他「復原磁碟變更」技術方法的情況下,還原快照集可能是指回歸到有一個以上的系統 (都來自原始虛擬機器) 現在彼此相衝突的情況 (或甚至是與原始來源系統衝突,如果它也被還原的話)。所以任何快照集或差異磁碟關聯上應該要先執行 Sysprep。

最佳化

大部分虛擬化技術都包含虛擬機器新增功能或工具,可協助改進從主機與虛擬系統互動的效能和經驗。在各種效能增強中,通常包括最佳化滑鼠和鍵盤輸入的工作,此外也包括改進的複製和貼上 (或其他主機對虛擬系統) 互動。部署前,請在您的虛擬系統中安裝這些工具的最新版本。

您還必須確保用戶端記憶體已針對虛擬作業系統經過最佳化的設定,並且與其將要部署的主機一致。您最不想碰到的情況是將一個要使用主機系統 1GB RAM 的 Windows XP 映像部署到實際上沒有那麼多 RAM 的主機系統。

另外也要記住當今大多數虛擬技術的限制 — 重要的是讓您的使用者知道如何與附加到虛擬系統的周邊設備互動,以及哪些應用程式可以在虛擬作業系統上運作,哪些不可以 (例如,大部分虛擬作業系統不支援 DirectX9 或 10,或是支援舊版的能力有限)。使用者可能不曉得那是什麼意思或它如何表現出來 (有些應用程式無法妥善處理處理這類失敗)。

主機的考量事項

要注意的是,關於執行虛擬化技術的主機電腦,無論當下執行的是完整的作業系統或是直接在硬體上執行的 Type 1 Hypervisor,通常都沒有什麼好擔心的。大多數虛擬化技術的設計會確定虛擬作業系統對主機一無所知 (或是不需要知道太多)。不過請確保您知道哪些主機正在使用中,以免從一部主機移往另一部主機的虛擬系統發生問題。也確定您曉得虛擬化廠商的產品在特定平台上的限制。因為您雖然可能可以在平台間移動,還是可能在過程中遺失或獲得主機 OS Type 2 Hypervisor (虛擬化應用程式) 的某些功能。

其他部署機制

相關 Sysprep 連結

下列文件可提供您許多使用 Sysprep 的協助:

使用 Sysprep 或磁碟複製 (或直接執行 Sysprep 然後複製虛擬機器) 是部署虛擬系統明顯的選擇,但還有其他方法。事實上,無論您是使用映像處理或安裝程式,使用 Windows PE 搭配虛擬化可能比搭配實體機器還要簡單,因為您處理的是 ISO 檔案,而不是實體 CD。要注意的是,有些虛擬化技術不太能處理 DVD 媒體,所以請確實向您的虛擬化廠商洽詢支援事宜。您可以使用 winnt32 或 setup.exe (在 Windows Vista 或 Windows Server 2008 的情況下),但是並沒有什麼特別的好處。如果您使用其他 Microsoft 部署技術,像是 Automated Deployment Services,您的虛擬化技術會支援 PXE 展開以網路為基礎的部署,就跟使用 RIS 或 WDS 一樣。

移轉

最後,除了實際移轉整部電腦外,別忘了使用者狀態移轉工具 (USMT)。USMT 可讓您將使用者的設定從實體用戶端輕鬆移動到新的虛擬系統上。因此,若是您的使用者想要將舊資料和設定移轉到新的虛擬機器上,舉例來說,您可以輕鬆取得 Windows XP 的檔案和設定,將這些檔案和設定儲存到 UNC,然後再發送到新的虛擬機器。

Wes Miller 現居德州的奧斯丁。他之前任職於同樣位在奧斯丁的 Winternals Software,並且曾在 Microsoft 擔任 Windows 的專案經理與產品經理。您可以透過電子郵件與 Wes 聯絡:technet@getwired.com

© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利;未經允許,嚴禁部分或全部複製.