On 10/14/2014 11:52 AM, Jd wrote:
Hi
* Trying to get drive-backup command, getting permission denied. :(
sudo virsh qemu-monitor-command --hmp my-instance --cmd
drive_backup drive-virtio-disk0 /tmp/foo.vda.img
Ouch. qemu-monitor-command is explicitly unsupported, precisely because
it goes behind libvirt's back and is likely to get libvirt confused.
Most likely, the reason permission is denied is that you are failing to
set the sVirt permissions of the file you are trying to use (this
includes setting all of SELinux/apparmor labels, the disk lease manager,
and cgroup ACLs). You really are better off experimenting on raw qemu
without libvirt, or else waiting for (or helping to patch) libvirt to
drive the command directly, as trying to issue the raw monitor command
while libvirt is still managing the domain is a recipe for disaster, as
you just found.
Looks like apparmor issue. What can I modify to make this work ?
* Couple of other questions
drive-backup :
* The doc seems to claim that it gives a point in time copy of
the drive. So I assume that no need to take any snapshot etc.. and merge
back in.
My understanding of the qemu command is that given:
[base] <- [active]
calling drive-backup will create:
[base] <- [snapshot](frozen at point of command)
\- [active](still modified by guest)
* does it internally use snapshot ? Does this hook in to doing
fsfreeze and unfreeze using guest agent and does it automagically ? I
do not see any options here.
I have not yet had time to look into wiring up libvirt to drive the
command; the libvirt solution will probably have the optional ability to
quiesce the file system around the snapshot event, similar to the
existing --quiesce flag of virDomainSnapshotCreateXML (in fact,
virDomainSnaphostCreateXML might even BE the interface we use to wire up
the qemu drive-backup command)
* Suppose I have base <-- sn1 --<-- sn2 (QEMU active) . does
it take data from sn2 only ? or base+sn1+sn2 .. full drive and creates
a new qcow2 sparse file.
If I understand the qemu command correctly, you have three choices via
the 'sync' option: the entire disk (the snapshot is a flat image
containing contents of base+sn1+sn2 with no backing file), a shallow
copy (the snapshot is a qcow2 file containing contents of sn2 with
backing file of sn1), or all new I/O (the snapshot file is populated
only when additional writes occur to sn2; the more writes into the
snapshot, the more sn2 has diverged from the point in time you created
the snapshot; which might be more useful once persistent dirty bitmap
tracking is added to qemu). You may get better answers to questions
like this on the qemu list, since libvirt can't drive it yet.
