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

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

On Wed, Oct 15, 2014 at 01:56:20PM -0700, Jd wrote:
> 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 ?
By "throw libvirt off" if you mean this: as the VM is running QEMU CLI
(with QMP server) behind the back of libvirt, assuming this same VM
was being managed by libvirt until that point -- in that sense, yes,
what you say is probably correct.

-- 
/kashyap