[Libguestfs] Concurrent scanning of same disk

[NoxDaFox]

2015-05-28 10:40 GMT+03:00 Richard W.M. Jones <rjones at redhat.com>:

> On Thu, May 28, 2015 at 10:33:48AM +0300, NoxDaFox wrote:
> > To create the snapshots I'm using the libvirt command snapshotCreateXML
> > with no flag set. Does libvirt support consistent snapshotting or shall I
> > rely on QEMU backup new feature only?
>
> According to: http://wiki.libvirt.org/page/Snapshots
> virDomainSnapshotCreateXML is only consistent if the guest is paused
> during the operation.
>
> The new qemu feature is called drive-backup
> (http://wiki.qemu.org/Features/IncrementalBackup).  Unless things
> changed recently, it is not exposed through libvirt, so the only way
> to use it is by sending qemu monitor commands
> (
> http://kashyapc.com/2013/03/31/multiple-ways-to-access-qemu-monitor-protocol-qmp/
> ).
>
> This is all pretty bleeding edge.  I still think you'd be better off
> just ignoring snapshots that fail and moving on to the next one.
>
> Rich.


I might be missing something then as the guest is actually paused during
the acquisition of the snapshot.

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.

Maybe I am breaking the disk's consistency once I extract the dump through
the qemu-img command?

The command is:
qemu-img convert -f qcow2 -o backing_file=guest_disk.qcow2 -O qcow2 -s
snapshot_n guest_disk.qcow2 new_disk_for_libguestfs.qcow2

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?

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20150528/1accbadb/attachment.htm>