I'm not quite sure I understand the point.
Let's see all the picture of async snapshot: our goal is to minimize a VM
downtime during the snapshot.
When we do async snapshot we save vmstate except RAM when a VM is stopped
using the current L1 table (further initial L1 table). Then, we want the VM
start running
and write RAM content. At this time all RAM is write-protected.
We unprotect each RAM page once it has been written.
Oh, I see, you're basically doing something like postcopy migration. I
was assuming it was more like regular live migration, except that you
would overwrite updated RAM blocks instead of appending them.
I can see your requirement then.
All those RAM pages should go to the snapshot using the initial L1 table.
Since the VM is running, it may want to write new disk blocks,
so we need to use a NEW L1 table to provide this ability. (Am I correct so
far?)
Thus, if I understand correctly, we need to use two L1 tables: the initial
one to store RAM pages
to the vmstate and the new one to allow disk writings.
May be I can't see a better way to achieve that. Please, correct me if I'm
wrong.
I guess I could imagine a different, though probably not better way: We
could internally have a separate low-level operation that moves the VM
state from the active layer to an already existing disk snapshot. Then
you would snapshot the disk and start writing the VM to the active
layer, and when the VM state write has completed you move it into the
snapshot.
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).
Kevin