Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in different AioContext

[Eric Blake]

On 5/19/20 10:48 AM, Vladimir Sementsov-Ogievskiy wrote:

> > The other options is doing what you suggested. There is nothing in the
> > qcow2 on-disk format that would prevent this, but we would have to
> > extend the qcow2 driver to allow I/O to inactive L1 tables. This sounds
> > like a non-trivial amount of code changes, though it would potentially
> > enable more use cases we never implemented ((read-only) access to
> > internal snapshots as block nodes, so you could e.g. use block jobs to
> > export a snapshot).
>
> Or export a snapshot through NBD.
>
> Still, I have one more idea, probably we already discussed it?
> Honestly, I don't like the fact that we store vmstate into guest-data 
> space. After EOF, invisible, but still..
>
> Maybe, it would be good to make a qcow2 extension for storing vmstate 
> separately?

The existing location of internal snapshots IS already stored separately 
from guest-data space, precisely because it is beyond EOF.

> So snapshot metadata will include two more fields: 
> vmstate_offset and vmstate_length (hmm, actually we already have the 
> second one), which will be allocated as normal qcow2 metadata?

How will adding redundant fields help?  Both fields are already present 
in the snapshot table of v3 images (even if indirectly) by virtue of:

        32 - 35:    Size of the VM state in bytes. 0 if no VM state is 
saved.
                    If there is VM state, it starts at the first cluster
                    described by first L1 table entry that doesn't 
describe a
                    regular guest cluster (i.e. VM state is stored like 
guest
                    disk content, except that it is stored at offsets 
that are
                    larger than the virtual disk presented to the guest)

                    Byte 40 - 47:   Size of the VM state in bytes. 0 if 
no VM
                                    state is saved. If this field is 
present,
                                    the 32-bit value in bytes 32-35 is 
ignored.

                    Byte 48 - 55:   Virtual disk size of the snapshot 
in bytes

which gives you both the 64-bit size (in order to compute the last 
cluster accessible to the guest, and thus the next cluster available to 
the vmstate beyond EOF) and the 64-bit length of that vmstate.

> Or we can 
> add one-two levels of layered allocation if needed, but keep it separate 
> from L1/L2 tables for guest clusters.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org