1 files changed, 46 insertions, 0 deletions
diff --git a/results/classifier/118/none/728 b/results/classifier/118/none/728
new file mode 100644
index 00000000..9fb540f0
--- /dev/null
+++ b/results/classifier/118/none/728
@@ -0,0 +1,46 @@
+device: 0.667
+architecture: 0.646
+virtual: 0.624
+network: 0.556
+files: 0.555
+graphic: 0.447
+hypervisor: 0.447
+kernel: 0.438
+permissions: 0.418
+semantic: 0.414
+PID: 0.376
+performance: 0.372
+register: 0.353
+boot: 0.342
+socket: 0.339
+ppc: 0.335
+vnc: 0.328
+mistranslation: 0.322
+risc-v: 0.261
+arm: 0.246
+TCG: 0.219
+debug: 0.186
+assembly: 0.165
+x86: 0.142
+user-level: 0.120
+i386: 0.110
+VMM: 0.094
+peripherals: 0.082
+KVM: 0.017
+
+Catch up to latest VHDX v2(=0x01) rev-7.0 specification
+Additional information:
+Below issues need to be addressed before or during the tackling of this issue.
+- ~#727 VHDX is corrupted on expansion.~
+- #136 windows qemu-img create vpc/vhdx error due to sparse files
+- #1605 On windows, 2nd kind vhdx-dyn bug, crash on Unexpected error in bdrv_check_qiov_request() in io.c 
+- #806 Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts
+- 
+This VHDX support applies to qemu build on any architecture, not just the windows-build.
+
+It is very likely, that the native hypervisor on windows WHPX will be the main hypervisor displacing haxm/vbox etc. VHDX, if it works, seems to be the virtual-disk format that is ideal 
+- for Linux/windows dual-boot machines, 
+- for clusters with Linux/windows servers sharing images from a network-storage  
+- for WSL2/Hyper-V
+
+Following a similar line of thought, NTFS/ExFat may be ideal for sharing data/images between Linux and Windows. So the storing, modification and drive attachment of VHDX files on these filesystems need to be just as well-tested as native Linux filesystems. As their driver are internal-kernel-drivers and not fuse/dokan-drivers, on both operating-systems, they are also performant.