On Fri, Feb 26, 2021 at 15:29:45 -0300, David Wells wrote: > > El 25/2/2021 a las 11:37, Peter Krempa escribió: > > On Wed, Feb 24, 2021 at 14:49:19 -0300, David Wells wrote: > > > Hi all! > > > > > > I've been using libvirt for some time and until now I have treated backups > > > of virtual computers as if they where physical computers installing the > > > backup client on the guest. I am now however facing the need to backup a > > > couple a couple of guest at the host level so I've been trying to catch up > > > by reading, googling and by trial and error too. Up to now I've been able to > > > backup a live machine whith a command like the following > > > > > > > virsh snapshot-create-as --domain test --name backup --atomic --diskspec > > > > vda,snapshot=external --disk-only > > > This command creates a file test.backup and in the meantime I can backup the > > > original test.qcow2 but for what I saw this disk image is in a "dirty" > > > state, as if the machine I could restore from this file had been turned off > > > whithout a proper shutdown. > > > > > > I know that I can later restore the machine to its original state by issuing > > > a command like this > > > > > > > virsh blockcommit --domain test vda --active --pivot > > > > virsh snapshot-delete test --metadata backup > > > I have seen that it is possible to create the snapshot using a memspec > > > parameter which would make the backup of the guest as if it where in a clean > > > state, however I haven't found the equivalent of the blockcommit for the > > > memory file, in a sort of speak, to be able to restore the guest to it's > > > original state. > > The memory image file doesn't depend on any other state nor does the VM > > use it after the snapshot is taken, if you don't need it you can delete > > it. > > > > The disk overlay you create by 'virsh snapshot-create-as' records only > > differences to the original image, but for memory state it doesn't make > > much sense as the memory is small and changes a lot, so we take a > > snapshot of the whole memory. > > > > Now to restore the state of a VM to a snapshot taken with memory, > > libvirt's native APIs for reverting don't work on external snapshots > > yet. > > > > You can use 'virsh restore memimg' to load VM's state as the memory > > snaphsot images have the same format as images created by 'virsh save'. > > > > Please note though that the configuration of the VM is taken from the > > save image if you do so, which includes paths to disk images, which may > > no longer be correct or desired, but virsh save-image-edit can be used > > to modify the XML if needed. > > > Hi all! > > Peter, thank you very much for your reply! So if I understood correctly > there is no way, at this time, to backup a live guest in a way that I can > restore it to a "clean" state. Also, if I understood correctly, the No you misunderstood. Creating an external snaphsot with --memspec in fact creates a state capture which can be completely restored in terms of consistency of filesystems and in-memory data. What currently isn't possible is to use the virDomainRevertToSnapshot API to do so, but there are manual steps which can be taken to do so. Obviously state beyond the VM can't be restored, so network connections existing at the time of the snapshot will be broken. > probability of a corrupt system on restore of the vm is minimized having the > qemu guest agent installed on the guest and issue the virsh > create-snapshot-as with the --quiesce parameter, is this correct? Yes that is correct, the filesystem is still mounted but the guest agent ensures that caches were flushed before. AFAIK the guest agent even provides guest-OS side hooks which allow to flush databases and others which are not filesystem bound to have the on-disk state as clean as possible.
