深入瞭解 Windows Server 2008 核心變化
概覽:
●記憶體管理和 SMB 2.0
●NTFS 自修復功能、Windows 硬體錯誤報告體系和驅動程式驗證程式
●I/O 完成埠、執行緒池和 NUMA 的可伸縮性
●Hyper-V 虛擬化
Windows Server 2008 是最新版本的 Microsoft 伺服器平臺，它包含許多系統級更改，這些更改涉及作業系統的所有功能領域：從記憶體管理到執行緒排程，從網路連線到安全(這裡只列出了少數幾個)。
由於 Windows Server® 2008 和 Windows Vista® SP1 的核心相同。只有其中的少數功能僅特定於客戶端且並未包含在 Windows Server 2008 中，如 SuperFetch、ReadyBoost、ReadyDrive、ReadyBoot 和多媒體類計劃程式服務 (MMCSS)。
因此，我將不再重複介紹 Windows Vista 中已介紹過且 Windows Server 2008 中同樣包含的重要核心變化，如 I/O 優先順序排列、新的引導體系結構 BitLockerTM、程式碼完整性和強制完整性級別。我將重點介紹之前這些文章中未涉及到的關鍵變化，包括與可靠性、效能、可伸縮性以及新的 Microsoft 管理程式計算機虛擬化技術 Hyper-VTM 相關的變化。
同樣，與之前的文章一樣，本文的範圍僅限於作業系統核心 Ntoskrnl.exe 以及與其緊密關聯的系統元件的變化。例如，本文不會介紹安裝(WIM 或 Windows® 映像格式和基於元件的服務)、管理(組策略和 Active Directory® 改進)、常規診斷和監控(Windows 診斷基礎結構)、核心網路(新的防火牆和 TCP/IP 實現)、Server Core 或伺服器角色的變化。
用於多處理器系統
系統的其中一項底層變化是 Windows Server 2008 僅提供設計用於多處理器系統的核心版本。過去，Windows 擁有專門針對單 CPU 計算機上的單處理器的版本，因為該版本可通過忽略僅在多處理器環境下需要的同步程式碼來獲得稍好一點的效能。隨著硬體速度變得越來越快，由優化帶來的效能提高几乎可忽略不計，並且如今的大多數伺服器系統都包含多個處理器，所以已不再需要單處理器的核心版本。
Windows Server 2008 核心的各個版本，系統中具體使用哪個版本取決於作業系統是除錯版本(Checked 版本)還是零售版本、安裝為 32 位還是 64 位(Itanium、Intel 64 或 AMD64)，以及如果是 32 位安裝，系統的實體記憶體是否超過 4GB 或支援資料執行保護 (DEP)。Windows Server 2008 還可能是最後一個提供 32 位版本的 Windows Server 作業系統。
| 核心 32 位 64 位 多處理器 是 是 多處理器 Checked 版本 是 是 多處理器實體地址擴充套件 (PAE) 是 否 多處理器 PAE Checked 版本 是 否 |
記憶體管理
試驗：檢視大規模的磁碟 I/O 操作
可使用 TechNet Sysinternals Process Monitor之類的檔案系統監視工具來檢視 Windows Server 2008 系統上的大規模檔案 I/O 操作。
有多種方法均可產生大規模 I/O 操作。如果有另一個執行 Windows Vista Service Pack 1 或 Windows Server 2008 的系統，可在頭一個伺服器上執行 Process Monitor 並監控到第二個系統的檔案複製。還可以通過執行非常耗費記憶體的程式使得記憶體管理器將頁面寫出到分頁檔案中，從而產生大規模的分頁檔案 I/O 操作。
圖 A 顯示了在 Windows XP 系統中執行非常耗費記憶體的程式後 Process Monitor 的輸出，此時在 Process Monitor 的“Options”(選項)選單中選中了“Enable Advanced Output”(啟用高階輸出)選項，並將過濾器設定為僅顯示到分頁檔案 pagefile.sys 的寫入。“Detail”(詳細資訊)列顯示寫入大小為 64KB。
圖 A
如果在 Windows Server 2008 上執行相同的步驟，則很可能出現類似圖 B 中顯示的輸出，它顯示大多數寫入大小約為 1MB。
圖 B
Windows Server 2008 中的記憶體管理器包含多項效能增強功能。例如，與 Windows Server 2003 相比，從分頁檔案提取資料或對對映檔案執行預讀 I/O 時，它將使用數量更少但規模更大的磁碟 I/O。I/O 系統中的變化是促成更大規模的檔案 I/O 的前提，它去除了自 Windows NT® 的第一個版本以來一直存在的 64KB 的 I/O 大小限制。
並且，必須注意：與 Windows Server 2003 相比，使用 Windows Server 2008 時，Cache Manager 從對映檔案進行預讀(猜測性讀取)的資料讀取通常要大兩倍，並且將直接進入待機列表(系統的程式碼和資料快取)。這種行為取代了 Cache Manager 對映虛擬記憶體並將資料讀入系統工作集(由記憶體管理器為系統分配的記憶體)的需要，而這種需要可能導致其他使用中的程式碼或資料被不必要地驅出工作集。
當把資料寫入分頁檔案時，記憶體管理器也會執行更大規模的 I/O。儘管 Windows Server 2003 常常執行比 64KB 還小的寫入操作，但在 Windows Server 2008 中，記憶體管理器通常使用 1MB 的寫入操作。
除通過減少寫入分頁檔案的次數來提高效能外，較大規模的寫入操作還可減少分頁檔案中的碎片。而它又反過來減少了讀回多個頁面所需的讀取次數和磁碟尋道次數，因為如果不相鄰，讀取和尋道次數都會多得多。
記憶體管理器還會嘗試寫出其他已修改頁面(這些頁面與將要寫出到所擁有程序的地址空間中的頁面相鄰)，並且會將分頁檔案放到已包含其他相鄰頁面的區域中。這種方法也可儘量減少碎片並提高效能，因為那些可能會最終寫出到分頁檔案中的頁面均已被寫入。此外，它還減少了引入大量相鄰程序頁面所需的分頁讀取次數。檢視側欄“試驗：檢視大規模的磁碟 I/O 操作”瞭解有關記憶體管理器使用大規模的 I/O 方面的更多資訊。
SMB 2.0
自從檔案服務功能被引入到 Windows 中以來，伺服器訊息塊 (SMB) 遠端檔案系統協議(也稱為通用 Internet 檔案系統 (CIFS))就已成為 Windows 檔案服務的基礎。在過去的幾年中，SMB 的設計限制制約了 Windows 檔案服務的效能和利用新的本地檔案系統功能的能力。例如，單個訊息能傳輸的最大緩衝區大小為約 60KB，並且 SMB 1.0 無法識別 Windows Vista 和 Windows Server 2008 中新增的 NTFS 客戶端符號連結。
Windows Vista 和 Windows Server 2008 引入了 SMB 2.0，它是客戶端和伺服器都支援時 Windows 所使用的一種新型遠端檔案服務協議。除能正確處理客戶端符號連結和其他 NTFS 增強功能外，SMB 2.0 還使用批處理來最小化客戶端和伺服器之間的資訊交換數量。批處理可提高廣域網 (WAN) 之類高延遲網路的吞吐量，因為它允許同時傳輸更多資料。
SMB 1.0 針對單個檔案按順序執行 I/O，而 SMB 2.0 則實現了 I/O 管道，從而可針對同一檔案執行多個併發 I/O。它通過衡量客戶端用於未完成 I/O 的伺服器記憶體數量來決定管道的深度。
由於 Windows I/O 記憶體管理器和 I/O 系統以及 TCP/IP 接收視窗自動調節方面的變化和檔案複製引擎的改進，SMB 2.0 顯著提高了吞吐量並減少了大型傳輸的檔案複製時間。由於兩種作業系統都實現了 SMB 2.0，所以部署 Windows Server 2008 檔案伺服器和 Windows Vista 客戶端即可使用 SMB 2.0 並實現這些效能優點。
使用 NTFS 自修復功能提高可靠性
可靠性是一個關鍵伺服器屬性，Windows Server 2008 提供各種改進來幫助管理員順暢執行其伺服器(包括線上 NTFS 一致性修復、新的硬體錯誤報告體系以及對驅動程式驗證程式的擴充套件)。
由於現在使用的儲存裝置一般都以 TB 為單位，因此對某個捲進行離線一致性檢查可能會使服務中斷數小時。鑑於許多磁碟損壞都侷限於單個檔案或部分元資料，Windows Server 2008 實現了新的 NTFS 自修復功能，即可在卷保持聯機的情況下修復損壞。
當 NTFS 檢測到損壞時，它將阻止訪問受損的檔案並建立一個系統工作執行緒，該執行緒將對受損資料結構執行類似 Chkdsk 的修復，完成後再允許訪問修復後的檔案。在此操作期間仍然可以正常訪問其他檔案，因而最小化服務中斷。
WHEA 基礎結構
Windows Server 2008 中包含有 Windows 硬體錯誤報告體系 (WHEA) 基礎結構，它可以簡化硬體故障管理並主動響應非致命錯誤。伺服器通常都有嚴格的正常工作時間保證，因此及時確定並響應此類系統中的錯誤至關重要。
通過對利用線上崩潰分析 (OCA) 提交到 Microsoft 的崩潰進行分析表明：約 10% 的作業系統崩潰是源於硬體故障，但確定此類崩潰的根本原因卻非常困難甚至於不可能，因為崩潰時所獲取的硬體錯誤資訊非常少。此外，在 Windows Server 2008 之前，Windows 並不內建支援監控裝置的執行狀況，也未實現故障前的修復或通知。其原因在於硬體裝置並未使用一種通用的錯誤格式並且不支援錯誤管理軟體。
WHEA 為各種平臺裝置(包括處理器、記憶體、快取和類似 PCI 和 PCI Express 之類的匯流排)提供了統一的錯誤源發現和報告機制。其原理是實現圖 2 中所示的體系結構，其中核心是錯誤源呼叫來報告錯誤的核心 API。此 API 要求所有錯誤都以同一方法進行格式化，然後使用 Windows 事件跟蹤 (ETW) 事件來記錄錯誤(嚴重錯誤則在重啟後再記錄)。
圖 2 WHEA 錯誤報告基礎結構
ETW 早在 Windows 2000 中就已引入，而當 ETW 使用 WHEA 後，硬體製造商和軟體供應商就可輕鬆地開發利用 WHEA 事件的裝置診斷管理應用程式。如果某事件已嚴重到足以導致系統崩潰，WHEA 會確保將該致命錯誤記錄儲存到崩潰轉儲檔案中，這樣管理員就可確定崩潰的根本原因。
WHEA 的另一關鍵部分是位於 %Systemroot%/System32/Pshed.dll 中的平臺特定的硬體錯誤驅動程式 (PSHED)。核心與 PSHED 連結，而它與平臺和韌體硬體連線，實質上是用作錯誤通知和 WHEA 錯誤報告 API 之間的轉換層。Microsoft 為每種平臺體系結構(x86、x64、Itanium)提供有一種 PSHED 並且 PSHED 公開了外掛模型，所以硬體供應商和製造商可使用特定於其平臺的行為來覆蓋預設行為。
最後，與其他錯誤源相連的系統元件 — 包括裝置驅動程式、硬體抽象層 (HAL) 和核心 — 可實現底層硬體錯誤處理程式 (LLHEL)(它將首先處理錯誤狀況)。LLHEL 的工作是從裝置中提取錯誤資訊，通知 PSHED 允許其收集其他平臺錯誤資訊，然後呼叫核心的 WHEA 錯誤報告 API。
驅動程式驗證程式
從 Windows 2000 起，每個 Windows 副本中都包含有驅動程式驗證程式，它是一個用於跟蹤出錯的裝置驅動程式和故障硬體的強大工具。管理員通常將驅動程式驗證程式(%Systemroot%/System32/Verifier.exe) 配置為密切監控可能導致系統崩潰的可疑裝置驅動程式的行為。驅動程式驗證程式可捕獲非法驅動程式操作，這樣崩潰轉儲檔案就可以直接指出罪魁禍首。
之前驅動程式驗證程式的缺陷在於大多數配置更改都需要重新啟動系統，而生產伺服器明顯不願出現這種情形。Windows Server 2008 中的驅動程式驗證程式通過取消最有用驗證的重啟要求而改進了這一過程，因此可在不重新啟動系統的情況下對出現問題的伺服器進行故障排除。
此外，驅動程式驗證程式還引入了三種新的驗證(如圖 3 所示)。安全檢查確保裝置驅動程式在用於與應用程式連線的物件上設定了安全許可權。強制掛起 I/O 請求測試了驅動程式對於需立即完成而非一段延遲後再完成的非同步 I/O 操作的恢復能力。雜項檢查則確認驅動程式有無錯誤釋放使用中的資源、錯誤使用 Windows 管理規範 (WMI) 註冊 API 以及洩漏資源處理程式。
圖 3 選中 Windows Server 2008 選項的驅動程式驗證程式
可伸縮性
可伸縮性是指作業系統或應用程式有效利用多個處理器和大量記憶體的能力。Windows 的每個版本都會通過減少或取消使用鎖(它們會降低多處理器的平行性)來提高可伸縮性，Windows Server 2008 也不例外。
執行計時器超時的程式碼中有一個較小但卻非常重要的改進，即不再需要排程程式鎖(所有底層同步操作都會使用的一種系統範圍排程程式鎖)。從而降低了 CPU 同步開銷，使得 Windows Server 2008 終端伺服器系統能比 Windows Server 2003 多支援約 30% 的併發使用者。
Windows Server 2008 中的其他可伸縮性改進包括完成埠增強功能、新的執行緒池實現、更加有效地使用非一致記憶體訪問 (NUMA) 硬體以及動態系統分割槽。
改進了 I/O 完成埠處理
大多數可伸縮的 Windows 伺服器應用程式(包括 IIS、SQL Server® 和 Exchange Server)都依靠稱為完成埠的一個 Windows 同步 API 來最大程度減少執行 I/O 操作時在多個執行緒之間的切換。具體方法是首先將新到請求(如 Web 伺服器客戶端連線)通知與完成埠關聯起來，並指定一個執行緒池來專門等待通知。當請求到來時，Windows 將排程一個執行緒，該執行緒通常執行其他 I/O 操作(如從磁碟讀取一個網頁並將其傳送到客戶端)來完成該請求。
因此，相同執行緒可儘快地返回以等待更多的客戶端請求，執行緒非同步執行 I/O 並將 I/O 完成與完成埠關聯起來。執行緒隨後返回等待完成埠，當新請求到來或某個 I/O 完成時，完成埠將排程該執行緒。通過這種方式，同一執行緒在 CPU 上始終處於活動狀態：處理客戶端請求或等待完成埠。
之前 Windows 版本中完成埠的缺陷在於：當 I/O 完成後，I/O 系統將讓執行該 I/O 的執行緒立即執行一小段完成處理，而不考慮該執行緒當前正在執行的其他工作。如果還有其他執行緒處於活動狀態，則常常會導致排程程式搶佔活動執行緒，並上下文切換到另一個執行執行緒的情況。
通過將完成處理延遲到下一執行緒以等待與該 I/O 關聯的完成埠，Windows Server 2008 避免了此類上下文切換。因此，即使還有另一執行緒正在等待完成埠，它仍會在執行其他程式碼之前先執行完成處理，而且排程程式不必切換到執行執行緒。這種最小化上下文切換的能力可顯著地改善高負載伺服器應用程式的可伸縮性。
執行緒池更加有效
利用多個 CPU 來寫入應用程式非常困難，因此 Windows XP 引入了工作執行緒池，它是一種基礎結構和相關 API，用於提取在多個 CPU 間執行小段工作的詳細資訊。 應用程式將工作專案指定給執行緒池 API，然後該 API 在它為系統中的每個 CPU 建立和管理的某個執行緒中執行這些工作專案。
執行緒池的目的是通過使用相同的執行緒連續執行多個工作專案來儘可能減少上下文切換。當某個執行緒因為忙於執行其他工作而無法達到此目的時，它將使用不同 CPU 上的另一執行緒來執行該工作專案。
Windows Server 2008 的執行緒池實現可間接地(受益於完成埠改進)和直接地(通過優化執行緒管理)更好利用 CPU，這樣工作執行緒就能根據需要動態切換以便處理應用程式的負荷。並且，此基礎結構的核心已轉移到核心模式，從而最小化使用該 API 的應用程式所產生的系統呼叫數量。最後，新 API 使應用程式能夠更輕鬆地執行某些操作，如在應用程式關閉期間中止已排隊的工作單元。
NUMA 優化
Windows Server 2003 線上程排程程式和記憶體管理器中引入了 NUMA 優化，而 Windows Server 2008 在 I/O 管理器中添加了 NUMA 優化同時擴充套件了記憶體管理器的 NUMA 優化。
NUMA 系統通常是多處理器系統，其中的記憶體延遲隨訪問它的處理器不同而有所不同(請參見圖 4)。記憶體被分成多個節點，CPU 和節點之間的延遲可能各不相同，並且每個 CPU 都被視為它可最快訪問的那個節點的一部分。
圖 4 示例 NUMA 系統
NUMA 系統(尤其是具有超過八個 CPU 的系統)通常比一致記憶體訪問系統更加經濟且效能更高。一致記憶體訪問系統必須平等地為所有 CPU 提供記憶體，而 NUMA 系統則能夠為直接連線到 CPU 的記憶體提供高速互連，同時為與 CPU 相隔較遠的記憶體提供較為便宜但更高延遲的連線。
為能在 NUMA 系統中有效擴充套件，作業系統或應用程式必須瞭解節點拓撲結構，以便使計算能夠在包含計算資料和程式碼的記憶體附近執行。例如，Windows 排程程式為每個執行緒分配一個所謂的理想處理器，該處理器是排程程式試圖始終在其上執行該執行緒的 CPU。這樣做可以使執行緒置於 CPU 快取中的資料能夠儘可能地在每次該執行緒執行時可用。
在 Windows Server 2003 中，排程程式擴充套件此概念的方法是：將包含理想處理器的節點視為該執行緒的理想節點，並且當理想處理器正忙於執行另一個執行緒時，排程程式會嘗試在理想節點中的另一個 CPU 上排程該執行緒。Windows Server 2003 記憶體管理器也支援 NUMA，並且在可能的情況下，它會將執行緒的記憶體分配定向到正在執行此執行緒的節點的記憶體中。
在 Windows Server 2008 中，記憶體管理器將核心的非分頁記憶體緩衝區(核心和裝置驅動程式用於儲存必需儲存在 RAM 中的資料的記憶體)分到各個節點，這樣可以在產生分配的節點上為執行緒分配記憶體。系統頁表項 (PTE) 是從發生分配的節點中分配，如果需要新頁表頁來滿足記憶體分配，則會按照在 Windows Server 2003 中所採取的方式在相同的節點記憶體中分配，而不會從任何其他節點的記憶體中分配。
在 Windows Server 2003 中，當執行緒進行記憶體分配時，記憶體管理器在分配記憶體時將優先考慮線上程當前執行的節點中進行分配。如果執行緒暫時排程到非理想節點，則在此期間執行的所有分配操作都將在非理想節點中執行。所以，當執行緒最終回到其理想節點中執行時，它將不再像最初一樣緊挨著所分配記憶體中儲存的資料或程式碼。
為解決這一問題，在 Windows Server 2008 中，記憶體管理器在所有執行緒記憶體分配時都將優先考慮執行緒的理想節點，即使執行緒正在另一節點附近執行。記憶體管理器還能自動了解處理器和節點之間的延遲，所以當理想節點中沒有足夠的可用記憶體時，它會檢查與理想節點最近的另一節點。此外，當執行緒引用程式碼或資料時，記憶體管理器將把其待機列表中的頁面遷移到執行緒的理想節點。
希望控制分配位置的應用程式可使用新的 NUMA 記憶體 API，它使這些應用程式能夠為記憶體分配、檔案對映檢視和檔案對映物件指定首選節點。對於與檔案對映相關的分配，記憶體管理器會檢查對映操作是否指定節點，然後檢查檔案對映物件是否指定節點，如果兩者都未指定，則最後它將回來繼續選用執行緒的理想節點。
在 Windows Server 2008 之前，用於儲存或網路 I/O 的中斷及其相關的延緩程序呼叫 (DPC) 能夠在任意 CPU 上執行，包括在與啟動 I/O 操作處於不同節點的 CPU 上執行。這有可能導致 I/O 操作中的資料讀取或寫入在訪問資料的節點以外的其他節點的記憶體中執行。
為避免這種情況，Windows Server 2008 I/O 系統將 DPC 執行定向到啟動 I/O 操作的節點中的 CPU，並且擁有支援 PCI 匯流排 MSI-X(訊息訊號中斷標準的擴充套件)裝置的系統還可以通過使用裝置驅動程式來進一步讓 I/O 在本地完成，因為這些裝置驅動程式將利用 Windows Server 2008 API 將 I/O 中斷定向到啟動該 I/O 的處理器。
動態分割槽
讓系統更具伸縮性的一種方法是讓其支援動態增加硬體資源(如 CPU 和記憶體)。如果這些資源無需重啟系統即可實現更換，則此支援還能使系統更具可用性。
Windows Server 2003 支援動態記憶體新增功能，從而使得具有動態記憶體支援的伺服器能在管理員新增的同時即可使用這些 RAM。Windows Server 2008 還擴充套件了動態記憶體支援，因為它可實現記憶體更換。
RAM 由於越來越依賴糾錯碼 (ECC) 校正而非常容易發生故障，因此在支援動態更換的伺服器上，Windows Server 2008 可透明地將出現故障的記憶體條中的資料遷移到替換記憶體上。具體過程為：首先遷移作業系統所控制的資料，然後將硬體裝置置於低功耗狀態來有效關閉它們，遷移記憶體中的剩餘資料，接著恢復裝置電源繼續正常操作。
Windows Server 2008 還支援處理器的動態新增和動態更換。對於動態更換，硬體必須支援備用 CPU 概念，當現有 CPU 產生故障指示時，備用 CPU 可聯機或動態新增到系統中，目前僅高端系統支援此概念。Windows Server 2008 排程程式可減緩故障 CPU 上活動的速度，並將工作轉移至替換硬體上，隨後可取出故障 CPU 並將其更換為新的備用件。
Windows Server 2008 支援處理器的動態新增，因此管理員能在不停機的情況下升級伺服器的處理能力。但是，排程程式和 I/O 系統只能將新 CPU 提供給那些通過新 API 請求 CPU 到達通知的裝置驅動程式和應用程式，因為某些應用程式內建假定 CPU 數量對於引導會話而言是固定的。例如，應用程式可能為每個 CPU 分配一個工作佇列，執行緒執行時將使用與該 CPU 關聯的佇列。如果排程程式將該應用程式的某個執行緒排程到新的 CPU 上，它可能會試圖引用並不存在的佇列，因而可能導致損壞應用程式的資料並很有可能致使該應用程式崩潰。
基於 Microsoft 伺服器的應用程式(如 SQL Server 和 Exchange Server)能支援 CPU 動態新增，一些核心 Windows 程序也支援此功能，包括 System 程序、會話管理器程序 (%SystemRoot%/System32/Smss.exe) 和 Generic Service Hosting 程序 (%Systemroot%/System32/Svchost.exe)。其他程序也可使用 Windows API 來請求新 CPU 到達通知。當新 CPU 到達時，Windows 將向裝置驅動程式通知這一情況、啟動 CPU 並隨後通知所寫入的裝置驅動程式和應用程式使用新的 CPU，這樣它們就可以在需要時分配資料結構以跟蹤新 CPU 上的活動。
計算機虛擬化
在 Windows Server 2008 之前，Microsoft 就已經使用宿主虛擬化技術(如圖 5 所示)實現了包括 Virtual Server 2005 在內的各種虛擬化產品。在宿主虛擬化中，虛擬機器的實現技術是在宿主作業系統上(通常是作為裝置驅動程式)執行的虛擬機器監控器 (VMM)。VMM 依賴宿主作業系統的資源管理和裝置驅動程式，並且當宿主作業系統排程其執行時，它會在活動虛擬機器 (VM) 之間對 CPU 切分時間片。
圖 5 宿主計算機虛擬化
Hyper-V(以前的代號為“Viridian”)是利用管理程式虛擬化得以實現的。管理程式完全控制著所有硬體資源，甚至引導系統和用於控制 VM 的 Windows Server 2008 作業系統本身實質上也是以虛擬機器的方式執行(如圖 6 所示)。
圖 6 Hyper-V 體系結構
管理程式可將系統分成多個 VM，並將 Windows Server 2008 的引導例項當作主分割槽(或根分割槽)，以使其可直接訪問各種硬體裝置(如磁碟、網路介面卡和圖形處理器)。管理程式要求根分割槽執行電源管理並響應硬體即插即用事件。它將擷取子分割槽中啟動的硬體裝置 I/O 並將其路由到根分割槽，然後根分割槽使用標準 Windows Server 2008 裝置驅動程式來執行硬體訪問。通過這種方式，執行 Hyper-V 的伺服器可以充分利用 Windows 對硬體裝置的支援。
當將 Windows Server 2008 配置為具有 Hyper-V 伺服器角色時，Windows 將把 hypervisorimagelaunchtypeboot 引導配置資料庫 (BCD) 設定設為 auto，並將 Hvboot.sys 裝置驅動程式配置為在引導過程的前期啟動。如果配置了該選項，Hvboot.sys 將使系統做好虛擬化準備，然後將 %Systemroot%/System32/Hvax64.exe 或 %Systemroot%/System32/Hvix64.exe 載入到記憶體中，具體載入哪個程式取決於系統是實現 AMD-V 虛擬化擴充套件還是 Intel VT CPU 虛擬化擴充套件。
載入完成後，管理程式使用虛擬化擴充套件將自身插入到 Windows Server 2008 中。使用者模式的應用程式使用 x64 處理器的 Ring 3 許可權級別，而核心模式程式碼則在 Ring 0 上執行，因此管理程式實際是在概念許可權級別 Ring -1 上執行，因為它可控制 Ring 0 上執行的程式碼的執行環境。
當使用 Hyper-V 管理控制檯建立或啟動子分割槽時，它將利用 %Systemroot%/System32/Drivers/Winhv.sys 驅動程式來與管理程式通訊，該驅動程式使用公開記錄的 hypercall API 來指示管理程式建立指定實體記憶體大小的新分割槽和執行特徵。根分割槽中的 VM 服務 (%Systemroot%/System32/Vmms.exe) 為每個子分割槽建立一個 VM 工作程序 (%Systemroot%/System32/Vmwp.exe) 以管理子分割槽的狀態。
Windows 改善子 VM 作業系統效能的其中一種方法是 Windows Server 2008 和 Windows Vista 都已實現的啟發方法(即僅當作業系統執行實現 Microsoft hypercall API 的管理程式時才會啟用的程式碼序列)。通過直接請求管理程式的服務，子 VM 避免了在管理程式必須猜測子作業系統的意圖時所產生的虛擬程式碼開銷。
例如，未實現自旋鎖(執行底層多處理器同步)啟發方法的來賓作業系統將停在一個緊湊迴圈上旋轉以等待其他虛擬處理器釋放自旋鎖。此旋轉可能會阻塞其中一個硬體 CPU，直到管理程式排程第二個虛擬處理器。在啟發式作業系統中，自旋鎖程式碼會在將要發生旋轉時通過 hypercall 通知管理程式，這樣管理程式可以立即排程另一個虛擬處理器並降低不必要的 CPU 使用。
Windows Server 2008 改善 VM 效能的另一種方式是加速 VM 對裝置的訪問。可通過在子作業系統中安裝統稱為“VM 整合元件”的一個元件集合來增強效能。
如果執行未安裝整合元件的 VM，則子作業系統將為管理程式所提供的模擬裝置配置硬體裝置驅動程式。當裝置驅動程式試圖使用硬體資源時，管理程式必須進行干預以便通知根分割槽，根分割槽將代表子 VM 作業系統使用標準 Windows 裝置驅動程式執行裝置 I/O。由於單獨的高階 I/O 操作(例如讀磁碟)可能包含多個離散的硬體訪問，所以它可能導致管理程式和根分割槽中出現許多稱為“擷取”的轉換。
Windows Server 2008 使用以下三種元件來最小化擷取：虛擬機器匯流排驅動程式 (%Systemroot%/System32/Drivers/Vmbus.sys)、虛擬服務客戶端 (VSC) 和虛擬服務提供商 (VSP)。當利用受支援作業系統將整合元件安裝到 VM 中時，VSC 將取代裝置驅動程式的角色，並使用子 VM 中的 Vmbus.sys 驅動程式服務，通過管理程式的 hypercall 和記憶體共享服務將高階 I/O 請求傳送到根分割槽中的虛擬機器匯流排驅動程式。在根分割槽中，Vmbus.sys 將請求轉發到相應的 VSP，然後它通過根分割槽的裝置驅動程式來啟動標準 Windows I/O 請求。