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

[Jd]

On 10/14/14, 1:08 PM, 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.
Thanks for the tip.
>>         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)
 From what I gather, libvirt cant help out with the quiesce here. from 
what I understand, libvirt consumes the drive-backup ... so if it wraps 
driver-backup with freeze - unfreeze, the system will be frozen for the 
duration of the copy which is not useful.

>
>>            * 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.
I get the first two. Dont get "all new I/O" ? new since when ?
Do we have qemu users list ? I subscribed to qemu-devel and it has 
200+emails.. difficult to look for relevant information/conversation.
One reason to ask questions here... is to get how to use this qemu 
feature in the "blessed" manner eventually. :)

Thank you.
>