Re: [Libguestfs] Concurrent scanning of same disk
2015-05-28 10:40 GMT+03:00 Richard W.M. Jones <rjones(a)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-proto...
).
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?
Attachments:
- attachment.html (text/html — 2.5 KB)