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
|
graphic: 0.857
device: 0.825
virtual: 0.727
architecture: 0.724
performance: 0.718
files: 0.672
PID: 0.627
arm: 0.548
register: 0.515
risc-v: 0.494
semantic: 0.486
permissions: 0.484
vnc: 0.483
boot: 0.467
debug: 0.463
peripherals: 0.453
user-level: 0.448
ppc: 0.447
mistranslation: 0.410
socket: 0.404
kernel: 0.398
TCG: 0.322
VMM: 0.279
network: 0.268
assembly: 0.203
i386: 0.201
hypervisor: 0.186
KVM: 0.164
x86: 0.158
On windows, preallocation=full qcow2 not creatable, qcow2 not resizable
Description of problem:
Not possible to create a fixed-virtual-disk qcow as one may do on linux.
One sometimes may want to create a fixed size qcow2, as can be done with the fixed variants of VHDX, VMDK, VDI,
The advantage of a fixed virtual-disk format, such as fixed-VHDX, fixed-VMDK, fixed-VDI is that it keeps the disk-meta-data as a header bundled along with that is essentially a raw image, allowing for seamless tooling and management of virtual-disks
Workaround use a raw file as diskimage. (see workaround given below)
To be very general, the implementation of this may need to factor in what underlying operations (fallocate, fallocate_punchhole, truncate, sparse) are supported by what filesystems (NTFS, ExFAT, ext4), choice of filesystem-driver (sometimes the driver may not have yet implemented an underlying operation), and operating systems (Linux/Win), and possible workarounds to achieve the same effect in the absence of underlying-operation.
Steps to reproduce:
1. open command shell
2. run the qemu-img command. In my case, qcow2 file is attempted to be created on a drive with ExFAT filesystem.
Additional information:
|