<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-05-28 10:40 GMT+03:00 Richard W.M. Jones <span dir="ltr"><<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Thu, May 28, 2015 at 10:33:48AM +0300, NoxDaFox wrote:<br>
> To create the snapshots I'm using the libvirt command snapshotCreateXML<br>
> with no flag set. Does libvirt support consistent snapshotting or shall I<br>
> rely on QEMU backup new feature only?<br>
<br>
</span>According to: <a href="http://wiki.libvirt.org/page/Snapshots" target="_blank">http://wiki.libvirt.org/page/Snapshots</a><br>
virDomainSnapshotCreateXML is only consistent if the guest is paused<br>
during the operation.<br>
<br>
The new qemu feature is called drive-backup<br>
(<a href="http://wiki.qemu.org/Features/IncrementalBackup" target="_blank">http://wiki.qemu.org/Features/IncrementalBackup</a>).  Unless things<br>
changed recently, it is not exposed through libvirt, so the only way<br>
to use it is by sending qemu monitor commands<br>
(<a href="http://kashyapc.com/2013/03/31/multiple-ways-to-access-qemu-monitor-protocol-qmp/" target="_blank">http://kashyapc.com/2013/03/31/multiple-ways-to-access-qemu-monitor-protocol-qmp/</a>).<br>
<br>
This is all pretty bleeding edge.  I still think you'd be better off<br>
just ignoring snapshots that fail and moving on to the next one.<br>
<span class=""><br>
Rich.</span></blockquote><div><br></div><div>I might be missing something then as the guest is actually paused during the acquisition of the snapshot.<br><br></div><div>I pause the guest, take a screenshot, a core dump and a snapshot, then I resume the guest. Proof is that I can clearly analyse the memory core dump without any problem.<br><br></div><div>Maybe I am breaking the disk's consistency once I extract the dump through the qemu-img command?<br><br></div><div>The command is:<br>qemu-img convert -f qcow2 -o backing_file=guest_disk.qcow2 -O qcow2 -s snapshot_n guest_disk.qcow2 new_disk_for_libguestfs.qcow2<br><br></div><div>Could it be that, as the backing file is pointing to the guest's disk which will evolve in time, when guestfs tries to read the data sees incosistencies?<br><br></div><div>The guest_disk.qcow2 is a COW clone of a base_disk.qcow2, what if I rebase the new_disk_for_libguestfs.qcow2 to the base_disk.qcow2?<br></div></div><br></div></div>