blob: 9fb540f03bd5abf2035068e57325989d4c343141 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
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.
|