Re: [libvirt-users] drive-backup command permission denied.. and need some clarification

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 ?