[libvirt-users] 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/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
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.
participants (3)
-
Eric Blake -
Jd -
Kashyap Chamarthy