On 10/15/14, 2:37 AM, Kashyap Chamarthy wrote:
On Tue, Oct 14, 2014 at 02:08:41PM -0600, Eric Blake wrote:
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. As an addendum, here's a small QMP example to test QMP 'drive-backup' command:
----------------------------------------------------------------------- #!/bin/bash
exec 3<>/dev/tcp/localhost/4444 echo -e "{ 'execute': 'qmp_capabilities' }" >&3 read response <&3 echo $response echo -e "{ 'execute': 'drive-backup', 'arguments': { 'device': 'drive-ide0-0-0', 'sync': 'full', 'target': '/var/lib/libvirt/images/backup-copy.qcow2', 'mode': 'absolute-paths', 'format': 'qcow2' } }" >&3 read response <&3 echo $response echo -e "{execute: 'query-block-jobs'}" >&3 -----------------------------------------------------------------------
Of course, the above assumes a QEMU instance is running with QMP server:
$ qemu-system-x86_64. . . -qmp tcp:localhost:4444,server
Thank you. This might come handy. But I guess this can still throw libvirt off ? right ? /Jd