Raw local disks for CS VMs

[akrasnov-drv]

Hi,
This is kind of follow up to #10468
Initially I had layered disks with shared base layer.
On suggestion from @rajujith I set disk offering to fat, and that made my VM disks independent. That helped to improve performance, still I have issues, e.g. fragmentation.

I'd want to use local raw pre-allocated disks, but so far have not found if it's possible with CS.
I tried providing template in raw format, nevertheless VMs get their disks in the same compressed qcow format.

If there is no way to use raw, maybe at least we can influence on other qcow options?
Our standard VMs have disks with

file format: qcow2
virtual size: 70 GiB (75161927680 bytes)
disk size: 66.5 GiB
cluster_size: 65536
Format specific information:
    compat: 0.10
    compression type: zlib
    refcount bits: 16

but CS disks get

file format: qcow2
virtual size: 70 GiB (75161927680 bytes)
disk size: 6.02 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false

with the same (I believe) load CS disk gets fragmented 10 times more than our non-CS VMs, and our original disk performance is a lot higher (compilation/linking is significantly faster)
Then is it possible to change compat and lazy refcounts? Maybe some other parameters?

The only ugly attempt to "inflate" the disk I have in mind is to create large file inside VM and then to remove it.
Not sure if it helps at all, but I'd prefer even not to try, if there are other options.

Any other suggestions are welcomed.
Thanks,
Alex.

[akrasnov-drv]

Just to confirm, if I upload raw template and want to start VM with fat disk from it, I see how CS brings original disk from secondary storage.

qemu-img convert -O qcow2 -U /mnt/e33ae501-61c1-3e72-85de-0af471342d8b/5cf75763-3031-31f6-9a13-f20157a9771e.raw /var/lib/libvirt/images/b4f0f85b-127a-468f-b6ce-842eeaa5dd54

[akrasnov-drv]

No, raw template gives nothing compared to qcow template, the resulting disks are the same.
I actually suspect there is a bug, because when I choose "fat" disk or "sparse" disk, I get exactly the same one.
I'd expect "fat" should give preallocated disk (even if qcow), but I get the same as for sparse (see my original message)

[akrasnov-drv]

I found in logs this values for my raw template
"directDownload":"false","deployAsIs":"false"
if deployAsIs was true, would it keep raw format? Where I can change this (if I can)?

[akrasnov-drv]

First of all I see that even if I upload template in raw format, the image used for deployment on agents is still qcow:

qemu-img info -U b4f0f85b-127a-468f-b6ce-842eeaa5dd54
image: b4f0f85b-127a-468f-b6ce-842eeaa5dd54
file format: qcow2
virtual size: 6 GiB (6442450944 bytes)
disk size: 5.14 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false

Then I caught an interesting thing. When I started VM with fat disk, first I saw disk create command:
qemu-img create -o preallocation=full -f qcow2 /var/lib/libvirt/images/9028b1ae-334f-47dd-a85c-4fc27da66946 6442450944
then convert into preallocated file:
qemu-img convert -O qcow2 -o preallocation=full -U --image-opts driver=qcow2,file.filename=/var/lib/libvirt/images/b4f0f85b-127a-468f-b6ce-842eeaa5dd54 /var/lib/libvirt/images/9028b1ae-334f-47dd-a85c-4fc27da66946
and then
qemu-img resize /var/lib/libvirt/images/9028b1ae-334f-47dd-a85c-4fc27da66946 64424509440

As you can see there is a logical issue here. It preallocates the size of original template, but then does resize without allocating disk space for it. As a result I get large disk in the same small space

image: /var/lib/libvirt/images/9028b1ae-334f-47dd-a85c-4fc27da66946
file format: qcow2
virtual size: 60 GiB (64424509440 bytes)
disk size: 6.01 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false

Should I open an issue for it?

[akrasnov-drv]

#10589