Server vNext 25941 and Server 2022 deduplication profile hyperv/VDI corrupts data
I have described it here too: https://techcommunity.microsoft.com/t5/windows-server-for-it-pro/server-2022-and-server-vnext-build-25931-corrupts-filesystem/m-p/3915647 and I just reproduced it with Server vNext 25941 right now - still the same behavior. "Ready to reproduce" package as VM to import into Windows 11 or Server 2022 - follow the text file on Desktop of the VM: Based on Server vNext 25941 (24 GB): https://joumxyzptlk.de/tmp/microsoft/SNEXT-25941.7z Based on Server 2022 (26 GB): https://joumxyzptlk.de/tmp/microsoft/S2022-Nested.7z The video when I tested with Server 2022, same behavior with 25941 and 25931: https://joumxyzptlk.de/tmp/microsoft/S2022-Nested_Deduplication_VDI-Hyperv_profile_kills_filesystem_v2.mp4 Has been reproduced on Windows 11 21H2/AMD 5950x/64 GB ECC RAM and i7-4960x/Server 2022 as host OS for above VM. If anyone else can reproduce it: Tell me. Would be nice. Minor problem with build 25941: Feedback hub does not open.
Deduplication on volumes doesn't work all the time, Start-Dedup job does nothing.
Any ideas on this? Winserver (2022) deduplication seems to be brittle. Works most of the time but sometime it stops and ceases to function. Been doing some testing to see how much space we could save using deduplication by loading a volume (VHD) with test data and attaching it to a winserver VM and testing dedupe on the that volume. Most of the time it works but some times Start-DedupJob completes within minute and does nothing and it refuses to do any work. Nothing in the event logs indicate any problems with it. Disabling/enabling dedupe and attempting garbage collection has no affect, The only way to get it working is to format the volume again and load data, reenable dedupe and start testing again. If that fails remove the dedupe feature completely and reinstall it.Server vNext 25987, 26010 (and Server 2022) deduplication corruption in nested-V setups
The deduplication corruption in the case of nested virtualization in Server 2022 and Server 25987 is still there. The package to reproduce for Server 25987: https://joumxyzptlk.de/tmp/microsoft/s-vnext-25987-dedup-problem-2023-11-03-exported-from-S2019.7z Server 2022 variant: https://joumxyzptlk.de/tmp/microsoft/S2022-nested-2023-09-30-exported-from-S2019-host.7z Host OS can be Server 2019, Windows 11 21H2 or Server 2022. CPU must be reasonable fast (i.e. from somewhere 'round 2018), support nested-v together with the Host OS (AMD and Intel CPU are fine). Host should have at least 24 GB RAM. The the "ready to reproduce package" must be unpacked to 😧 or higher drive letter which should be at least SATA SSD storage. Else the problem may not show up as predictable as it does here. These packages were exported from a Server 2019 host, HP DL 380 dual Xeon 6228R with 1 TB ECC RAM, so it is easier to reproduce since Exports from Windows 11 don't import so well on other hosts. Originally the bug showed up on a Ryzen 5950x with 64 GB ECC RAM. Reproduced with less than 50% chance on an i7-4960x 32 GB RAM with HDD storage, more than 50% on SSD storage. Server 2019 variant: Does exist, but there is no data corruption. How to use: Once unpacked to Non-System-Drive SSD storage import the the VM and follow the Textfile on the desktop. In short: Activate Hyper-V in that VM, default settings. Configure deduplication with default settings any profile in that VM for D:, start a dedup run. Check dedup rate. Should be above 50%, usually it is around 55%. Import those two VMs on drive 😧 of that VM: Start them both in parallel, and execute the Offline-Windows-Updates stored on the desktop. You won't make it past the first one.