[pve-devel] [PATCH v3 qemu-server 11/11] qcow2: add external snapshot support

[DERUMIER, Alexandre]

> 
> > > should this maybe have been vdisk_alloc and it just works by
> accident?
> It's not works fine with vdisk_alloc, because the volume need to be
> created without the size specified but with backing file param
> instead.
> (if I remember, qemu-img is looking at the backing file size+metadas
> and set the correct total size for the new volume)

>>I am not sure I follow.. we create a snapshot, but then we pretend it
>>isn't a file with backing file when passing it to qemu? this seems
>>wrong.. IMHO we should just allocate (+format) here, and then let
>>qemu do the backing link up instead of this confusing (and error-
>>prone, as it masks problems that should be a hard error!) call..
>>
>>
>>
>>
> >>Maybe a better way could be to reuse vdisk_alloc, and add backing
> >>file
> >>as param ?
>>
>>that seems.. wrong as well? the file can never be bigger just because
>>it has a backing file right? why can't we just allocate and format
>>the regular volume?

>>I need to redo tests as I don't remember exactly.
>>
>>From memory (I have wrote it 2month ago, sorry ^_^ ) , it was maybe :
>> - related with metadatas prealloc size + lvm size).

>> or (but I need to verify)
>>
>> The "blockdev-snasphot" qmp later, only change the backing-file in
>>memory in the blockgraph, but not inside the file itself. (so after a
>>restart of the process, the chain is borken).

Ok, I have redone tests and verify, this is the second case

The problem is that blockdev-snapshot don't actually rewrite the
backing file inside the qcow2 file.

It still explain on the same link:
https://lists.gnu.org/archive/html/qemu-block/2019-10/msg01404.html


So the only way, is to do it a qcow2 creation.

And then, that's why we need to pass backing=undef with doing blockdev-
add, because if not, qemu will try to open the file the the backing
already opened/locked.

Don't seem to be fixed in last qemu version, and libvirt is still doing
it this way too.