Incompatibilities and Compatibilities

NOTE: This article will be updated in the future when more compatibilities / incompatibilities are discovered. 

Incompatibilities

 

12-Feb-2022

• OPNSense (and potentially pfSense as well) CARP protocol is not compatible with Arista (7060CX-32S, and potentially other models) switches.
• [13-Feb-2022] OPNSense (and potentially pfSense as well) CARP protocol is not compatible with Windows Server 2022 Virtual Switches with SR-IOV enabled. Workaround is to NOT select SR-IOV option when creating the virtual switch.
  
• Windows Server 2022 (Host) with Windows 11 Guest VM: Nested Virtualization is not compatible with Discreet Device Assignment (DDA) and SR-IOV. Once both are enabled, all passed-through devices (including SR-IOV virtual functions) will fail to be started with the same reason "Insufficient System Resources".
  
• RME PCI-E Sounds Cards such as HDSPe RayDAT and HDSPe AIO are not compatible with Windows Discreet Device Assignment (DDA) and potentially all other device pass-through technologies. The device drivers can be installed on guest OS but it will not yield any sound.
• Datapath VisionAV PCI-E Capture Cards are not compatible with Windows Discreet Device Assignment (DDA) and potentially all other device pass-through technologies. The device drivers cannot be started properly in guest OS.
  

Windows Network Direct: Your better bet is with Windows Server 2019

I have been always struggling to get RDMA working inside a Windows virtual machine. I had tried Mellanox ConnectX-3, Mellanox ConnectX-5 and Chelsio T62100-LP-CR network adapters, with Windows Server 2012 or 2016, and even with Direct Device Assignment in Windows Server 2016, I could not get RDMA working flawlessly in any virtual machine.

Recently, I retried RDMA in a Windows VM (2019) on a Windows Server 2019 host, with a Chelsio T62100-LP-CR - and finally have RDMA (iWarp) working correctly (even without a switch - you can connect port 1 to port 2 to form a 100GbE link). It enabled SMB Direct between the VM and the host (and between VMs as well), and performance was acceptable (needs tuning).

If you are after any RDMA application inside a Windows VM, or simple just want to use SMB Direct in a VM, Windows Server 2019 or later is your better bet in this case.

Do note that you need the following:

• SR-IOV support from BIOS - this sometimes means enabling the ASPM option in BIOS.
• A network card that supports RDMA - I like iWarp because it is simpler (virtually no configuration needed). If you like RoCE then you may need DCB configured properly, or even need a 40GbE/100GbE switch.
• Windows Server 2019 or higher - both host and VM. You may use Windows 10 (latest) - I didn't try that out but theoretically it should work.
• Workstation / Server grade hardware - I have seen many times people complaining about not being able to enable SR-IOV due to missing implementation like IOMMU or ACS etc. with consumer grade hardware. Your CPU supports all these features doesn't mean your motherboard / BIOS has support of all features.

Windows Server 2016 DDA 直接設備授予虛擬機的一些要點

算是微軟的一些“突破”吧，反正 VMWare 一早就有這個技術。不論如何，至少直接把 PCI Express 設備，例如顯卡，聲卡，網卡或者 USB 3.0 端口授予虛擬機單獨訪問已經變得可能。然而并非所有設備都都能夠使用此功能。掃描了一下自己伺服器的硬件大概折這樣的：

1、老式 PCI 設備——別想了，放棄吧。
2、PCI Express 1.0 設備或者鏈路到 PCI Express 1.0 橋接芯片上的設備——也別想了，洗洗睡吧。
3、連路到 Intel PCH (就是現在有點想南橋的那個東東) 的設備——看運氣，就算你是 PCI Express 2.0，沒有 ACS (Access Control Service) 那也是別想了……什麽意思呢？就是板載的網卡，USB 3.0 口之類的，衹有是從 PCH 延伸出來的，就別想了……
4、有 ACS，但是是複合設備，那也別想了，至少我的 NVIDIA Quadro K4200 是不行的！

所以最終發現能夠 DDA 的就衹有直接連在 CPU 的根部 PCI Express 3.0 端口的設備，或者鏈路到支持 ACS 的 PCI Express 2.0 擴展盒的設備：
- Dell PERC H730P (別開玩笑了……把 100 個磁盤弄到 VM 裏面幹啥？)
- Mellanox ConnectX-3 (好吧，算是靠譜一點……)
- HP ioDrive DUO SLC 320GB (算不算 NVMe 直接授予！？-_-)

看來我那些 PCI Express 1.0 的 Expansion Backplanes / Enclosures 都沒啥用處了~

微軟已經修復 Windows Server 2016 TP 中的 Deduplication 數據損壞問題

近日收到 Microsoft 的消息說 Windows Server 2016 TP 中的 Deduplication 數據損壞問題已經被修復，并且附上了一個内部測試補丁。安裝該補丁之後，測試運行了幾次 DedupJob 均沒有問題。產生問題的是 dedup.sys 驅動程序。

看來微軟對於數據損壞此類嚴重問題還是比較重視的。如果閣下希望在 Windows Server 2016 TP 中使用 Deduplication，則需要等待補丁在 Windows Update 中的正式發佈。比較保險的應該會在下一個纍積更新之中，或者更保險一點可以等待至 TP5。注意必須先安裝補丁，然后再開啓 Deduplication 功能。從微軟工程師的描述中看來此問題可能衹會發生在從 Windows 2012 R2 升級到 2016 的系統中。

關於詳細問題描述可以參考此帖子。

[已修復] 注意 Windows Server 2016 TP 中的 Deduplication 可能會導致數據損壞

UPDATE: 此問題已修復。

不知道這算是幸運還是不幸，反正就被我遇上了。基本情況如下：

先決條件：
- 系統是 Windows 2012 R2
- 磁盤爲 GPT 的 NTFS，開啓 VDI 模式的 Deduplication，數據重複刪除率達到 75%
- 狀態: 1TB 中刪除重複后大約使用 250GB。
- 磁盤儲存大量 Windows 2008 R2 與 Windows 8.1 的 VM，格式爲 VHD 或者  VHDX
- 磁盤是本地磁盤，注意這個配置 Microsoft 不建議。沒有 SAN 或者 iSCSI 的使用。

步驟：
- 升級 Host 到 Windows 2016 TP4，并且安裝 Deduplication 功能
- 將所有 VM 導入到 Hyper-V，并且運行
- 添加更多的 VM
- 確保 Background Deduplication 運行至少一次

結局：
- 大部分 VM 突然進入 BSOD 狀態
- 檢查該 VM 的 VHD / VHDX 文件，發現無法用 CHKDSK 修復，數據完全丟失。卷返回 Invalid Function 錯誤。
- 該 VHD / VHDX 文件無法重複使用！你必須刪除該文件，然後重新創建，才能夠在 VM 中重新安裝系統
- Host 中開啓 Deduplication 的卷卻沒有問題，CHKDSK 通過。
- 關閉 Background Deduplication 后，就不會進一步損壞其他數據

所以此次數據損壞可能是 Dedup 服務造成的。已經將此問題報告 Microsoft，他們也在進一步調查，不過在他們回復之前，閣下最好還是先關閉 Dedup 服務以避免產生同樣的問題。

如何使用 USB 驅在 UEFI 系統上面安裝 Windows 2016

好吧，我知道 Windows 2016 衹是一個 Technical Preview, 不過貌似微軟忽略了一些非常重要的因素。TP 4 很大，比以前的 Server 操作系統都大，所以 install.wim 達到了 4.22GB。總所周知 UEFI 系統用 USB 盤安裝需要一些先決條件：

- FAT32 格式的 USB 盤
- 設置爲 Active Partition
- 複製 Windows 2016 安裝數據到 USB 盤中

最後一項很不幸對於 Windows 2016 TP4 是無法辦到的——install.wim 超過了 FAT32 所能夠承受的 4GB 極限！
解決辦法很簡單，用下面的命令切割 install.wim 文件：

Dism /Split-Image /ImageFile:l:\sources\install.wim /SWMFile:f:\install.swm /FileSize:3072

(L: 是光盤，F: 是硬盤)

然後把切割好的 install.swm 和 install2.swm 複製到 USB 盤的 sources 目錄裏面，這樣就可以完成所有先決條件了！

Dell PERC H710P：兼容性問題！！

這是舊事重提了，其實兩個 Dell PERC H710P 都已經出手。這款卡絕對是經典，性價比一流，比 LSI 自己原廠的要好得多，而且可以 Spin Down Configured Drives （忘記是否需要 MegaSCU 改了）。然而在一下的配置中存在致命問題：

配置：
- 非 UEFI 主板（可能無關聯……）
- 非 Dell 系統（可能有關聯……）
- Windows Server 2012 R2 (自帶最新的驅動程序)
- Dell PERC H710P

結局：Fatal Error - PERC Kernel Panic.........      >_<

解決辦法就是用非 Dell PERC H710P 的磁盤裝 Windows，然後降級到 Windows Server 2008 R2 的 PERC H710P 驅動程序……感覺糟透了……

驗證 Windows Server 2012 R2 的 Deduplication 是否可以作用在本機運行的 VHDX 上

根據微軟的論述，Windows Server 2012 R2 可以支持對正在運行的 VM 所使用的 VHDX 文件進行重復刪除處理（Deduplication），前提是 VHDX 文件與 Hyper-V 服務器不在同一個機器上面。

不過，既然微軟已經解決在 file locked 情況下對文件内容進行 Dedup，我想就算全部東西都在本機也應該沒有問題。

操作如下：
1、創建 3 個 VM，其 VHDX 文件都同在一個 SSD RAID 分區上面，佔約 33GB 空間
2、開啓 Dedup，選擇 VDI 選項，天數應該不要緊，VHDX 文件會被即時處理：

3、使用 PowerShell 運行 Start-DedupJob -Volume V: -Type Optimization
注意：此時 3 個 VM 都在運行中。
4、結果：

Dedup 成功。VM 運行不受影響。
至於好處那也是顯然易見的——在這個只有 300GB 的 SSD RAID 分區上，同時運行 30 個 VM 也不會覺得擁擠了。如果都只是基礎鏡像，所需的空間可能就 30-40GB 吧~~ :D 剩下的空間大有作爲啦！

Windows Server 2012 R2 RTM: 第二代 Hyper-V VM 儲存性能

Windows Server 2012 R2 RTM 針對 Hyper-V 有比較多的功能特性更新。其中最有代表性的就是，第二代的 VM 去掉了虛擬 IDE 控制器，被虛擬 SCSI 控制器取代。由於 SCSI 指令所需的模擬較少，此層面將會比 IDE 虛擬要薄，從而產生的性能損耗將會少得多。上一代的 VM 只能夠在非啓動槃上使用 SCSI 控制器，現在可以抛棄 IDE 模擬——前提是 Guest 操作系統必須是 Windows 8 或者 Windows 2012 (或以上~）。

下面作一個比較直觀的對比：

主機配置：
Intel Xeon W5580 x2
Tyan S7025
Dell PERC H710P
Intel X25-E x22
Intel RES2SV240 x2

好吧，已經比較過時的硬件，不過那些 Intel X25-E 還可以使用約 80 年……對，80 年……這也是爲什麽現在的 SSD 都是 MLC 而不是 SLC —— 不會坏的 SSD 廠商是不會盈利的~~

開啓了 Hypervisor 后，由於 VM 的硬盤活動，對主機的硬盤性能造成一定影響。一般情況下，主機的 AS SSD 分數應在 2700-2800 之間。分別測試下，得出下面的數據：

 

 

主板/北橋瓶頸了……





看看IOPS:

可以看出，在綫性存取方面，儲存性能已經比較貼近主機的直接訪問性能。4K IOPS 由於本身是 VHDX 的問題，讀寫會多一層，所以額外的操作會導致延遲，從而影響性能。至於最後的存取延遲測試，我覺得可能 VHDX 被 cached 了……

下面看看文件複製性能：

達到主機約 60-75% 的性能。
下面是壓縮測試：

有點令人驚訝的是，壓縮測試中 VM 與主機的性能一致。(Compression Test = 綫性存取？)

總體來説，PERC H710P + Tyan S7025 是沒有辦法完全發揮 22 個 Intel X25-E 的性能……好吧，跑題了，應該是說，Windows Server 2012 R2 在 VM 性能發揮上有比較明顯的提升。可以預期，加上 VHDX 文件的重復刪除 (Deduplication)，在 SSD 上跑 VM 將會是一件很愜意的事情——SSD 容量小的問題也有解決方法了。

而 MLC SSD 的用戶其實也不用怕讓 VM 在 SSD 上運行了。Windows Server 2012 自帶的 Storage Space 可以組成軟 RAID，而我個人覺得，由於此 RAID 還是在操作系統層面上，TRIM 是應該可以實現的，所以 MLC SSD 壽命在 RAID 的情況下也應該不會產生以前的致命問題。當然，3000-5000 次的刷寫極限，還是沒有辦法跟 50nm 大晶體的 100000 次刷寫極限對比的 (Intel X25-E Rocks!)

實現 Windows 2008 R2 與 MS-DOS 8.0 在 iSCSI 上雙重啓動：硬盤必須分配所有空間！

為什麽要用 DOS？其實理由還是很多的，例如：
- 運行 megaoem
- 更新主板 BIOS
- 更新/修改顯卡 BIOS
- 更新硬盤 BIOS
- 更新 RAID Controller BIOS
...

一直以來，我都是用一個額外的 USB 槃放置 DOS 的啓動文件然後進行以上的動作。不過有時候還是覺得不方便，主要是主板 BIOS 有點古怪，從 USB 啓動需要進去 BIOS 調整（把 USB 認作 HDD 了 -_-)，所以如果可以 Dual Boot 直接在啓動的時候有一個選擇那就最好。

DOS 肯定不在第一個分區，因爲第一個分區肯定是 Windows 7/2008 的 Bootmgr + 安裝源（不需要 DVD 或者 USB 槃，安裝文件就在第一個分區裏面！）。而使用的 DOS 版本是 8.0，起碼支持 FAT32。我的基本想法就是：

- 創建一個 VHD，在 Hyper-V 裏面調試好，可以進行 Dual Boot
- 把 VHD 挂在 iSCSI 上面，然後使用一台物理電腦通過 gPXE 嘗試啓動
- 把 VHD 用 Ghost 鏡像到物理硬盤，然後本機啓動（未測試）

可以想象，其實第二步（iSCSI）是最挑剔的，如果通過的話，最後一步基本沒難度。

好吧，實際的情況就是，VHD 准備好了，C 槃（第一個分區）是 Windows 啓動+安裝源，D 槃（第二個分區）是 DOS，用 DOS 下面的 Debug 命令創建 BOOTSECT.DOS，然后用 BCDEDIT 指向該文件，在 VM 裏面，DOS 啓動成功。

然而，儅把 VHD 挂載在 iSCSI 上，卻出現了極端詭異的情況：


Starting MS-DOS...


Missing Command Interpreter
Type the name of the Command Interpreter (e.g., C:\WINDOWS\COMMAND.COM)
A>


絕對的詭異~~VM 沒問題，Command.com 存在，然而卻找不到。
一開始以爲是硬盤的格式大小之類，嘗試幾個不同的簇大小，分區大小，不過還是一樣。

最後一發狠，把硬盤剩下的空間全部分配給 DOS 的分區，卻奇跡般的成了！

經過幾番測試終于判定 DOS 只會在這種情況下 Dual Boot:
- 硬盤不是動態硬盤
- 硬盤使用 MBR 分區
- DOS 槃必須是 Primary 分區，不過可以不是第一個
- DOS 分區必須在硬盤的前 127GB 以内（FAT32的說）
- 硬盤必須被使用完全，沒有未分配的空間！

現在是，C 槃 5GB (NTFS, 有 Windows 2008 R2 Setup)，D 槃 100MB (FAT32 DOS)，E 槃 (NTFS) 22GB 不過是空的，用來預留給 Windows。如果不分配 E 槃，DOS 就啓動不了~！

終于可以實現 Self-contained 鏡像，加個 GRUB 甚至可以直接挂載 ISO，不需要再用光驅，軟驅和 USB 了！