12:05 p.m.
Hi all,
Best wishes for 2021! :)
So I've been reading and playing around with live snapshots and still
haven't figured out how to use an external memory snapshot. My goal is to
take a disk+memory snapshot of a running VM and, if possible, save it in
external files.
As far as I understand, I can run:
$ virsh snapshot-create $VM
... and that'll take an *internal* live snapshot of a given VM, consisting
of its disks and memory state, which will be stored in the qcow2 disk(s) of
the VM. In particular, the memory state will be stored in the first disk of
the VM. I can then use the full range of snapshot commands available:
revert, list, current, delete.
Now, an external snapshot can be taken with:
$ virsh snapshot-create-as --domain $VM mysnapshot --diskspec
vda,file=/home/riccardo/disk_mysnapshot.qcow2,snapshot=external --memspec
file=/home/riccardo/mem_mysnapshot.qcow2,snapshot=external
... with as many "--diskspec" as there are disks in the VM.
I've read the virsh manual and the libvirt API documentation, but it's not
clear to me what exactly I can do then with an external snapshot, in
particular with the file containing the memory state. In articles from 7-8
years ago people state that external memory snapshots cannot be reverted...
is it still the case today? If so, what's a typical usage for such files?
If not with libvirt, is it possible to revert to an external memory + disk
state in other ways, for instance through qemu commands?
Thanks!
Riccardo
8:29 a.m.
On Fri, Jan 01, 2021 at 19:05:55 +0100, Riccardo Ravaioli wrote:
Hi all,
Hi,
Best wishes for 2021! :)
So I've been reading and playing around with live snapshots and still
haven't figured out how to use an external memory snapshot. My goal is to
take a disk+memory snapshot of a running VM and, if possible, save it in
external files.
As far as I understand, I can run:
$ virsh snapshot-create $VM
... and that'll take an *internal* live snapshot of a given VM, consisting
of its disks and memory state, which will be stored in the qcow2 disk(s) of
the VM. In particular, the memory state will be stored in the first disk of
the VM. I can then use the full range of snapshot commands available:
revert, list, current, delete.
Now, an external snapshot can be taken with:
$ virsh snapshot-create-as --domain $VM mysnapshot --diskspec
vda,file=/home/riccardo/disk_mysnapshot.qcow2,snapshot=external --memspec
file=/home/riccardo/mem_mysnapshot.qcow2,snapshot=external
... with as many "--diskspec" as there are disks in the VM.
I've read the virsh manual and the libvirt API documentation, but it's not
clear to me what exactly I can do then with an external snapshot, in
particular with the file containing the memory state. In articles from 7-8
years ago people state that external memory snapshots cannot be reverted...
Unfortunately that's still true. The external snapshot code provides
enough functionality that you are able to use them, but reverting and
deleting needs to be done manually. There are a few manuals floating
online but it always depends on what you want to achieve.
The unfortunate situation of the implementation not being finished (I've
certainly stated it here already, since this question happens from time
to time (which also means you should look through the archives and
you'll find some pointers how to do certain specific steps)) comes from
the fact that it provides enough functionality for higher level
management projects to control snapshots (oVirt, openstack) and too much
higher priority work.
is it still the case today? If so, what's a typical usage for
such files?
If not with libvirt, is it possible to revert to an external memory + disk
The memory image created by libvirt this way is actually in the same
image format as 'virsh save' and 'virsh restore' uses. This actually
does allow you to restore such a snapshot, although manual steps are
necessary. The most naive scenario, where you want to return to the
past state and you don't require returning back (alternate future is not
created) can be reverted simply by simply using 'virsh restore $IMG' and
then fixing the persistent definition of the VM to use the same disk
images as the memory image recorded.
Note that the overlay images which were created as part of the snapshot
are invalid after that point and must no longer be used.
Similarly, for non-active VMs or vms without memory snapshot you can
alter the image locations to use the old images and that effectively
reverts the snapshot.
Other operations are possible too, but please look through the archives
first.
state in other ways, for instance through qemu commands?
Thanks!
Riccardo
5:15 p.m.
On Sun, 3 Jan 2021 at 15:30, Peter Krempa <pkrempa(a)redhat.com> wrote:
Hi,
Hi Peter,
Thanks a lot for the prompt reply and for pointing me to the direction
("virsh restore" among all) and apologies for my very late reply.
In the past couple of weeks I had a thorough look at past messages in the
mailing list as well as linked tutorials, notes and slides.
The memory image created by libvirt this way is actually in the same
image format as 'virsh save' and 'virsh restore'
uses.
[...]
I think I bumped into two limitations for my particular use case, but I'd
like to double check with you, just in case I'm again missing something.
1) When creating an external online snapshot (disks+memory) of a qemu-KVM
VM, I'd like to store the backing files in a separate folder and rename the
newly-created delta files with the respective names of the original disks
(now the backing files). Is this possible at all? Say a VM has a disk
vm/disk1.qcow2 and I take an external snapshot, I'd like the backing file
to appear in snap/disk1.qcow2 and the new delta disk to appear as
vm/disk1.qcow2. Currently I wait for the VM to be shutdown by the user
before I move around disks as desired and run qemu-img rebase in unsafe
mode to update the delta disks. Can I accomplish the same result while the
VNF is running?
2) As you suggested, I now use "virsh restore" to launch a VM with the
memory state I had previously backed up. The "virsh restore" API applies to
a VM that is not running. However, I see that for internal snapshots,
libvirt also supports a snapshot-revert operation on a /live/ VM. Is this
possible at all with an external snapshot? If so, what are the commands
needed? My current way of automating a snapshot-revert with an external
online snapshot only applies to a shutdown VM. It consists in:
- shutting down the VM;
- erasing all its delta disks, replacing them with new ones;
- executing "virsh restore" on the memory state, making sure that the disk
paths referenced in the embedded XML file are correct.
Does this seem reasonable? Can I do the same while the VNF is running?
I suppose that for a snapshot-delete operation on a live VM I just need to
run "virsh blockpull" on each disk, but I couldn't figure out how to do a
revert.
Thanks again!
Riccardo
noon
Hi all,
Can I get some feedback on these two questions I posted a while back,
concerning external snapshots:
On Tue, 26 Jan 2021 at 00:15, Riccardo Ravaioli <riccardoravaioli(a)gmail.com>
wrote:
[...]
1) When creating an external online snapshot (disks+memory) of a
qemu-KVM
VM, I'd like to store the backing files in a separate folder and rename the
newly-created delta files with the respective names of the original disks
(now the backing files). Is this possible at all? Say a VM has a disk
vm/disk1.qcow2 and I take an external snapshot, I'd like the backing file
to appear in snap/disk1.qcow2 and the new delta disk to appear as
vm/disk1.qcow2. Currently I wait for the VM to be shutdown by the user
before I move around disks as desired and run qemu-img rebase in unsafe
mode to update the delta disks. Can I accomplish the same result while the
VNF is running?
2) As you suggested, I now use "virsh restore" to launch a VM with the
memory state I had previously backed up. The "virsh restore" API applies to
a VM that is not running. However, I see that for internal snapshots,
libvirt also supports a snapshot-revert operation on a /live/ VM. Is this
possible at all with an external snapshot? If so, what are the commands
needed? My current way of automating a snapshot-revert with an external
online snapshot only applies to a shutdown VM. It consists in:
- shutting down the VM;
- erasing all its delta disks, replacing them with new ones;
- executing "virsh restore" on the memory state, making sure that the disk
paths referenced in the embedded XML file are correct.
Does this seem reasonable? Can I do the same while the VNF is running?
I suppose that for a snapshot-delete operation on a live VM I just need to
run "virsh blockpull" on each disk, but I couldn't figure out how to do a
revert.
Thanks a lot!
Riccardo
1:47 a.m.
On Fri, Apr 09, 2021 at 19:00:41 +0200, Riccardo Ravaioli wrote:
Hi all,
Can I get some feedback on these two questions I posted a while back,
concerning external snapshots:
On Tue, 26 Jan 2021 at 00:15, Riccardo Ravaioli <riccardoravaioli(a)gmail.com>
wrote:
[...]
> 1) When creating an external online snapshot (disks+memory) of a qemu-KVM
> VM, I'd like to store the backing files in a separate folder and rename the
> newly-created delta files with the respective names of the original disks
> (now the backing files). Is this possible at all? Say a VM has a disk
> vm/disk1.qcow2 and I take an external snapshot, I'd like the backing file
> to appear in snap/disk1.qcow2 and the new delta disk to appear as
No, this is not possible during the snapshot operation, you can control
only the name of the new overlay image.
> vm/disk1.qcow2. Currently I wait for the VM to be shutdown by
the user
> before I move around disks as desired and run qemu-img rebase in unsafe
> mode to update the delta disks. Can I accomplish the same result while the
> VNF is running?
Very theoretically you can achieve the same during the lifetime of the
VM by using 'virsh blockcopy' with the following algorithm:
1) ensure you have a overlay image that is small enough (but that's what
the snapshot operation does if you do it right after snapshot).
Note that the snapshot target should be something temporary, you'll see
why below.
2) symlink/hardlink the original backing image (vm/disk1.qcow2) to the
new locaton
3) create an empty qcow2 overlay file with the desired name of the disk
_after_ snapshot, pointing to the hardlink of the new backing file
destination
4) use shallow 'blockcopy' with --reuse-external operation to move the
temp overlay to the file created in 3), this ensures that it's backing
image as described in the metadata is used
The above has IMO too many moving parts that can go wrong. I'd suggest
adapting to the "backwards" naming of the images which happens with
external snapshots.
> 2) As you suggested, I now use "virsh restore" to
launch a VM with the
> memory state I had previously backed up. The "virsh restore" API applies
to
> a VM that is not running. However, I see that for internal snapshots,
> libvirt also supports a snapshot-revert operation on a /live/ VM. Is this
> possible at all with an external snapshot? If so, what are the commands
No the operation is not implemented for external snapshots yet. The use
of 'virsh restore' is a workaround, which requires manual steps to
preserve images in certain scenarios.
> needed? My current way of automating a snapshot-revert with an
external
> online snapshot only applies to a shutdown VM. It consists in:
> - shutting down the VM;
> - erasing all its delta disks, replacing them with new ones;
> - executing "virsh restore" on the memory state, making sure that the
disk
> paths referenced in the embedded XML file are correct.
Yes that will sounds reasonable. Note that the XML embedded in the
saveimage points to the original base file so you'll always need to
modify it to use the new deltas.
> Does this seem reasonable? Can I do the same while the VNF is
running?
> I suppose that for a snapshot-delete operation on a live VM I just need to
> run "virsh blockpull" on each disk, but I couldn't figure out how to
do a
> revert.
No to use 'virsh restore' you must shutdown the VM, but note that in
many cases with internal snapshots libvirt will also need to terminate
and restart the QEMU process so this situation doesn't really differ.
In the internal snapshot code is way more complicated in order to
preserve the running process needlessly and I'd probably elect to always
restart qemu when reverting them nowadays.
The only drawback is that the remote video connection needs to be
reopened.
1350
days inactive
1451
days old
4 comments
2 participants
participants (2)
-
Peter Krempa -
Riccardo Ravaioli