[Qemu-devel] Combining -loadvm and -snapshot

[Qemu-devel] Combining -loadvm and -snapshot

[Drew DeVault]

I recently ran into an issue where I found I couldn't combine the
-loadvm and -snapshot flags, nor any conceivable combination of
alternate approaches like loadvm via the monitor. Independently, both
options work as expected, but together I get this error:

qemu-system-x86_64: Device 'virtio0' does not have the requested snapshot 'base'

The goal here is to resume the VM state from a snapshot, but to prevent
the guest from persisting writes to the underlying qcow2.

I started digging into the code to understand this problem more, and I
was pretty deep in the weeds when I realized what the underlying problem
probably was and the kind of refactoring necessary to fix it - so I'm
here to touch base before moving any further.

I believe this happens because -snapshot creates a temporary qcow2
overlaid on top of the disk you're using, and this overlay does not have
any snapshots copied, nor does any of the snapshot reading code (e.g.
qcow2_snapshot_list or qcow2_snapshot_goto) iterate over backing disks
to load their snapshots.

At first I was going to adjust the qcow2 snapshot loading code (those
two functions in particular) to read through their backends, but I'm a
little unfamiliar with this code and the refactoring is not minor so I
would like to get feedback from some of the wiser folks on this mailing
list before I sink too much time into this.

Thoughts?

--
Drew DeVault

Re: [Qemu-devel] Combining -loadvm and -snapshot

[Markus Armbruster]

Cc'ing the QCOW2 folks.

Drew DeVault <sir@cmpwn.com> writes:

> I recently ran into an issue where I found I couldn't combine the
> -loadvm and -snapshot flags, nor any conceivable combination of
> alternate approaches like loadvm via the monitor. Independently, both
> options work as expected, but together I get this error:
>
> qemu-system-x86_64: Device 'virtio0' does not have the requested snapshot 'base'
>
> The goal here is to resume the VM state from a snapshot, but to prevent
> the guest from persisting writes to the underlying qcow2.
>
> I started digging into the code to understand this problem more, and I
> was pretty deep in the weeds when I realized what the underlying problem
> probably was and the kind of refactoring necessary to fix it - so I'm
> here to touch base before moving any further.
>
> I believe this happens because -snapshot creates a temporary qcow2
> overlaid on top of the disk you're using, and this overlay does not have
> any snapshots copied, nor does any of the snapshot reading code (e.g.
> qcow2_snapshot_list or qcow2_snapshot_goto) iterate over backing disks
> to load their snapshots.
>
> At first I was going to adjust the qcow2 snapshot loading code (those
> two functions in particular) to read through their backends, but I'm a
> little unfamiliar with this code and the refactoring is not minor so I
> would like to get feedback from some of the wiser folks on this mailing
> list before I sink too much time into this.
>
> Thoughts?
>
> --
> Drew DeVault

Re: [Qemu-devel] Combining -loadvm and -snapshot

[Kevin Wolf]

Am 13.02.2019 um 07:07 hat Markus Armbruster geschrieben:
> Cc'ing the QCOW2 folks.
> 
> Drew DeVault <sir@cmpwn.com> writes:
> 
> > I recently ran into an issue where I found I couldn't combine the
> > -loadvm and -snapshot flags, nor any conceivable combination of
> > alternate approaches like loadvm via the monitor. Independently, both
> > options work as expected, but together I get this error:
> >
> > qemu-system-x86_64: Device 'virtio0' does not have the requested snapshot 'base'
> >
> > The goal here is to resume the VM state from a snapshot, but to prevent
> > the guest from persisting writes to the underlying qcow2.
> >
> > I started digging into the code to understand this problem more, and I
> > was pretty deep in the weeds when I realized what the underlying problem
> > probably was and the kind of refactoring necessary to fix it - so I'm
> > here to touch base before moving any further.
> >
> > I believe this happens because -snapshot creates a temporary qcow2
> > overlaid on top of the disk you're using, and this overlay does not have
> > any snapshots copied, nor does any of the snapshot reading code (e.g.
> > qcow2_snapshot_list or qcow2_snapshot_goto) iterate over backing disks
> > to load their snapshots.
> >
> > At first I was going to adjust the qcow2 snapshot loading code (those
> > two functions in particular) to read through their backends, but I'm a
> > little unfamiliar with this code and the refactoring is not minor so I
> > would like to get feedback from some of the wiser folks on this mailing
> > list before I sink too much time into this.
> >
> > Thoughts?

Reading from the backing file would be correct in your special case
(because the overlay was only just created and doesn't contain data
yet), but generally speaking, this would make the disk content
inconsistent because it would mix newer data from the overlay with old
data from the snapshot in the backing file.

But before I make suggestions how this could be addressed (it's probably
not trivial), let me ask what your real goal is?

I'm asking because when you start a VM with '-loadvm foo', this means
that you already got a snapshot at this exact point. So the guest will
write to the qcow2 file, but when you start the VM the next time, and
again with '-loadvm foo', the newly written data will be discarded and
QEMU will revert to the snapshot 'foo' again. So you already got the
same functionality that -snapshot is supposed to provide, even without
using it.

Do you have other reasons why you want to use -snapshot?

Kevin

Re: [Qemu-devel] Combining -loadvm and -snapshot

[Drew DeVault]

On 2019-02-13 11:46 AM, Kevin Wolf wrote:
> Reading from the backing file would be correct in your special case
> (because the overlay was only just created and doesn't contain data
> yet), but generally speaking, this would make the disk content
> inconsistent because it would mix newer data from the overlay with old
> data from the snapshot in the backing file.
> 
> But before I make suggestions how this could be addressed (it's probably
> not trivial), let me ask what your real goal is?
> 
> I'm asking because when you start a VM with '-loadvm foo', this means
> that you already got a snapshot at this exact point. So the guest will
> write to the qcow2 file, but when you start the VM the next time, and
> again with '-loadvm foo', the newly written data will be discarded and
> QEMU will revert to the snapshot 'foo' again. So you already got the
> same functionality that -snapshot is supposed to provide, even without
> using it.
> 
> Do you have other reasons why you want to use -snapshot?

The issue is that if I start with -loadvm foo, it will start from the
foo snapshot, but any changes will be written to disk. Since qcow2 is a
sparse format, a mean guest could fill up all of the sectors and balloon
the underlying disk. The next guest starts from the snapshot, too - but
the host is wasting disk space. I'm also not able to run several guests
from the same qcow2 at once - which is a non-starter.