Server 2022 and Server vNext build 25931 corrupts filesystem with deduplication profile HyperV/VDI

[Joachim_Otahal]

Actually I should double post this in "Windows Server for IT Pro" and "Windows Server Insider", but would this be rude?

Both Server 2022 and the newest Server vNext build 25931 have following behavior:
The deduplication profile HyperV, called VDI in GUI, can corrupt data, can corrupt the filesystem. Server 2019 show no such behavior. (Edit: Server 2016 and 2012 R2 are fine too)
How to reproduce as test: Create a VM with nested-V, add a second virtual drive where you copy some Hyper-V VMs. You can try on a physical host. I would have done that if I'd have a spare machine for that.
Activate deduplication with profile "VDI" on that second drive.
Start-DedupJob -Volume <the volume> -Type Optimization -Full -Wait
Start those nested VMs, do some actions within those nested VMs, like running Windows Updates. Shut them down, if they make it this far. Don't be surprised if they blue screen during Windows Updates.
Right after that run chkdsk /f again. It MAY show file system damage. Usually <NUMBER>.ccc and <NUMBER>.cd files of the deduplication chunk store which usually resides in \System Volume Information\Dedup\ChunkStore\{UNIQUE IDENTIFIER}.ddp\Data
I have "ready to reproduce" VM-packages there which use the freely available EVAL versions of Windows Server. Unpack, import into Windows 11 Hyper-V, in my case a Ryzen 5950x (with 64 GB ECC RAM). I reproduced that issue on an i7-4960x/Server2022 host as well. Read the prepared information file on the desktop.
Server 2022 as base (26 GB): https://joumxyzptlk.de/tmp/microsoft/S2022-Nested.7z
Server vNext build 25931 as base (22 GB): https://joumxyzptlk.de/tmp/microsoft/SNEXT-25931.7z

Video from July what is happening here: https://joumxyzptlk.de/tmp/microsoft/S2022-Nested_Deduplication_VDI-Hyperv_profile_kills_filesystem_...

Any advice here? I've been battling that for Server 2022 for three month now, it first appeared when I upgraded the Server 2019 VM "for nested VMs only for testing" to Server 2022 in June and took me a while to pin down what was going on.

[#2]

A little update on this: I could reproduce it on a HP DL380 Gen10 with a Dual Xeon Gold 6226R, full flash and 1 TB RAM, running Server 2019 on the host.

Seems this bug only surfaces on reasonable fast machines, and shows up with a higher probability when the "Ready-To-Reproduce" package is NOT on C: . The i7-4960x seems to be the lower limit, and it does not always show up when using the Tiered-SSD-HDD storage there, but always when using SSD storage. For my Ryzen it shows up on any SSD storage except when it is on C:. For the above mentioned DL380 C: is not big enough, so it was a non-system volume there too.

Ready-To-Reproduce Package for a Server 2019 host: https://joumxyzptlk.de/tmp/microsoft/S2022-nested-2023-09-30-exported-from-S2019-host.7z

Edit: That package does not require an internet connection to reproduce, therefore no LAN is configured for that VM.

[#3]

@Joachim_Otahal 

Wow, thanks for posting this!

AMD EPYC 7502P 32-Core, SSD, clean updated Win2022 LTSC, deduped 100 vhdx files with hyper-v profile - after 5 minutes files corrupted.

Tried another server with same config - same situation.

Disabled dedupe - everything great. 

😞 

[#4]

Fir thank you for reporting / confirming!
If you can, or have the time: Try with Server 2019. No dedupe problem there, at least none I stumbled upon. Or try a slower CPU :D.