summary refs log tree commit diff stats
path: root/gitlab/issues/target_missing/host_missing/accel_missing/728.toml
diff options
context:
space:
mode:
Diffstat (limited to 'gitlab/issues/target_missing/host_missing/accel_missing/728.toml')
-rw-r--r--gitlab/issues/target_missing/host_missing/accel_missing/728.toml28
1 files changed, 0 insertions, 28 deletions
diff --git a/gitlab/issues/target_missing/host_missing/accel_missing/728.toml b/gitlab/issues/target_missing/host_missing/accel_missing/728.toml
deleted file mode 100644
index 20f81ce9..00000000
--- a/gitlab/issues/target_missing/host_missing/accel_missing/728.toml
+++ /dev/null
@@ -1,28 +0,0 @@
-id = 728
-title = "Catch up to latest VHDX v2(=0x01) rev-7.0 specification"
-state = "opened"
-created_at = "2021-11-15T13:31:38.143Z"
-closed_at = "n/a"
-labels = ["Storage", "kind::Feature Request"]
-url = "https://gitlab.com/qemu-project/qemu/-/issues/728"
-host-os = "n/a"
-host-arch = "n/a"
-qemu-version = "n/a"
-guest-os = "n/a"
-guest-arch = "n/a"
-description = "n/a"
-reproduce = "n/a"
-additional = """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."""