libvirt users - Oct 2014 - drive-backup command permission denied.. and need some clarification

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

        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.
           * 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.
           * 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.

Thanks
/Jd

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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

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

-- 
/kashyap

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.
>