[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in differ
From: |
Eric Blake |
Subject: |
Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in different AioContext |
Date: |
Tue, 19 May 2020 11:06:00 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
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
- Re: [RFC PATCH 3/3] block: Assert we're running in the right thread, (continued)
- Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in different AioContext, Thomas Lamprecht, 2020/05/14
- Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in different AioContext, Kevin Wolf, 2020/05/14
- Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in different AioContext, Vladimir Sementsov-Ogievskiy, 2020/05/19
- Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in different AioContext, Denis Plotnikov, 2020/05/19
- Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in different AioContext, Kevin Wolf, 2020/05/19
- Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in different AioContext, Denis Plotnikov, 2020/05/19
- Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in different AioContext, Kevin Wolf, 2020/05/19
- Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in different AioContext, Vladimir Sementsov-Ogievskiy, 2020/05/19
- Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in different AioContext,
Eric Blake <=
- Re: [RFC PATCH 0/3] block: Synchronous bdrv_*() from coroutine in different AioContext, Denis Plotnikov, 2020/05/20