[libvirt] [PATCH] support auth for qemu SCSI hotplug
Hi all, commit fceeeda2 added support for adding key objects on hotplug based on a disk's secinfo for normal drives, but missed out SCSI drives. This patch adds the same support for SCSI drives, so that it's possible to hotplug SCSI drives requiring authentication (e.g. rbd-backed drives). Cheers, Gema Gema Gomez (1): qemu: hotplug: support auth for scsi hotplug src/qemu/qemu_hotplug.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) -- 2.10.0
Add any key objects to qemu when hotplugging a scsi drive with secinfo. Support for this was added in a previous commit for normal drives, but not for SCSI drives. --- src/qemu/qemu_hotplug.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 72dd93b..a450492 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -601,13 +601,16 @@ qemuDomainAttachSCSIDisk(virConnectPtr conn, char *devstr = NULL; bool driveAdded = false; bool encobjAdded = false; + bool secobjAdded = false; char *drivealias = NULL; int ret = -1; int rv; virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver); virJSONValuePtr encobjProps = NULL; + virJSONValuePtr secobjProps = NULL; qemuDomainDiskPrivatePtr diskPriv; qemuDomainSecretInfoPtr encinfo; + qemuDomainSecretInfoPtr secinfo; if (qemuDomainPrepareDisk(driver, vm, disk, NULL, false) < 0) goto cleanup; @@ -639,6 +642,12 @@ qemuDomainAttachSCSIDisk(virConnectPtr conn, goto error; diskPriv = QEMU_DOMAIN_DISK_PRIVATE(disk); + secinfo = diskPriv->secinfo; + if (secinfo && secinfo->type == VIR_DOMAIN_SECRET_INFO_TYPE_AES) { + if (qemuBuildSecretInfoProps(secinfo, &secobjProps) < 0) + goto error; + } + encinfo = diskPriv->encinfo; if (encinfo && qemuBuildSecretInfoProps(encinfo, &encobjProps) < 0) goto error; @@ -657,6 +666,15 @@ qemuDomainAttachSCSIDisk(virConnectPtr conn, qemuDomainObjEnterMonitor(driver, vm); + if (secobjProps) { + rv = qemuMonitorAddObject(priv->mon, "secret", secinfo->s.aes.alias, + secobjProps); + secobjProps = NULL; /* qemuMonitorAddObject consumes */ + if (rv < 0) + goto exit_monitor; + secobjAdded = true; + } + if (encobjProps) { rv = qemuMonitorAddObject(priv->mon, "secret", encinfo->s.aes.alias, encobjProps); @@ -682,6 +700,7 @@ qemuDomainAttachSCSIDisk(virConnectPtr conn, ret = 0; cleanup: + virJSONValueFree(secobjProps); virJSONValueFree(encobjProps); qemuDomainSecretDiskDestroy(disk); VIR_FREE(devstr); @@ -696,6 +715,8 @@ qemuDomainAttachSCSIDisk(virConnectPtr conn, VIR_WARN("Unable to remove drive %s (%s) after failed " "qemuMonitorAddDevice", drivealias, drivestr); } + if (secobjAdded) + ignore_value(qemuMonitorDelObject(priv->mon, secinfo->s.aes.alias)); if (encobjAdded) ignore_value(qemuMonitorDelObject(priv->mon, encinfo->s.aes.alias)); if (orig_err) { -- 2.10.0
On 10/09/2016 11:51 AM, Gema Gomez wrote:
Hi all,
commit fceeeda2 added support for adding key objects on hotplug based on a disk's secinfo for normal drives, but missed out SCSI drives. This patch adds the same support for SCSI drives, so that it's possible to hotplug SCSI drives requiring authentication (e.g. rbd-backed drives).
Cheers, Gema
Need to teach your mailer to truncate long lines... So could you provide a bit more information about the configuration. Are you indicating that you have an RBD pool with a volume that's being used as a SCSI device on the guest? Reason I ask - not modifying qemuDomainAttachSCSIDisk was by choice mainly because it's generally used with the iSCSI pool which at this point in time cannot support this new secret model. Tks, John
Gema Gomez (1): qemu: hotplug: support auth for scsi hotplug
src/qemu/qemu_hotplug.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
Hi John, On 13/10/16 21:37, John Ferlan wrote:
So could you provide a bit more information about the configuration. Are you indicating that you have an RBD pool with a volume that's being used as a SCSI device on the guest?
We are indeed using Ceph (RBD) pool volumes, attached via virtio-scsi to the guests.
Reason I ask - not modifying qemuDomainAttachSCSIDisk was by choice mainly because it's generally used with the iSCSI pool which at this point in time cannot support this new secret model.
Even though iSCSI doesn't support secrets this way, doesn't mean it isn't necessary for RBD. In particular, the current handling is inconsistent between domain creation and hotplugging of a volume. On domain creation, the secret object is added just fine. On hotplug, when libvirt talks to the qemu monitor, it tells qemu to create a virtio-scsi device, rbd-backed, with the secret pointing to a secret object. However, that secret object is *NOT* currently being inserted via the qemu mon communication, and so the command fails to actually attach the disk. Considering libvirt is already telling qemu on hotplug that there is some secret with a given name, it sounds logical to actually add that secret object. Plus, that's consistent, as I said, with how domain creation works. As for iSCSI not supporting it - I'm not sure I see the problem. The patch I submitted qualifies the creation of the aes key object with whether secinfo is present for the disk, and it's of AES type. And for reference, below is the conversation libvirt and the qemu monitor were having before this patch, including the XML. Since libvirt wasn't adding the scsi0-0-0-1-secret0 object, it all failed rather miserably. 2016-10-07 14:09:40.974+0000: 13608: info : qemuMonitorIOWrite:534 : QEMU_MONITOR_IO_WRITE: mon=0x7f7c00eb60 buf={"execute":"human-monitor-command","arguments":{"command-line":"drive_add dummy file=rbd:volumes/volume-e51d02fc-7399-4e51-bdde-84577ba79990:id=nova:auth_supported=cephx\\;none:mon_host=10.10.0.101\\:6789\\;10.10.0.111\\:6789\\;10.10.0.112\\:6789,file.password-secret=scsi0-0-0-1-secret0,format=raw,if=none,id=drive-scsi0-0-0-1,serial=e51d02fc-7399-4e51-bdde-84577ba79990,cache=none"},"id":"libvirt-14"} 2016-10-07 14:09:40.987+0000: 13608: info : qemuMonitorIOProcess:429 : QEMU_MONITOR_IO_PROCESS: mon=0x7f7c00eb60 buf={"return": "No secret with id 'scsi0-0-0-1-secret0'\r\n", "id": "libvirt-14"} len=79 for this XML: <disk type="network" device="disk"> <driver name="qemu" type="raw" cache="none"/> <source protocol="rbd" name="volumes/volume-e51d02fc-7399-4e51-bdde-84577ba79990"> <host name="10.10.0.101" port="6789"/> <host name="10.10.0.111" port="6789"/> <host name="10.10.0.112" port="6789"/> </source> <auth username="nova"> <secret type="ceph" uuid="some-uuid..."/> </auth> <target bus="scsi" dev="sdb"/> <serial>e51d02fc-7399-4e51-bdde-84577ba79990</serial> </disk> Thanks, Gema -- Gema Gomez-Solano Tech Lead, SDI Linaro Ltd IRC: gema@#linaro on irc.freenode.net
On 10/15/2016 10:04 AM, Gema Gomez wrote:
Hi John,
On 13/10/16 21:37, John Ferlan wrote:
So could you provide a bit more information about the configuration. Are you indicating that you have an RBD pool with a volume that's being used as a SCSI device on the guest?
We are indeed using Ceph (RBD) pool volumes, attached via virtio-scsi to the guests.
Reason I ask - not modifying qemuDomainAttachSCSIDisk was by choice mainly because it's generally used with the iSCSI pool which at this point in time cannot support this new secret model.
Even though iSCSI doesn't support secrets this way, doesn't mean it isn't necessary for RBD. In particular, the current handling is inconsistent between domain creation and hotplugging of a volume. On domain creation, the secret object is added just fine.
On hotplug, when libvirt talks to the qemu monitor, it tells qemu to create a virtio-scsi device, rbd-backed, with the secret pointing to a secret object. However, that secret object is *NOT* currently being inserted via the qemu mon communication, and so the command fails to actually attach the disk.
Considering libvirt is already telling qemu on hotplug that there is some secret with a given name, it sounds logical to actually add that secret object. Plus, that's consistent, as I said, with how domain creation works.
As for iSCSI not supporting it - I'm not sure I see the problem. The patch I submitted qualifies the creation of the aes key object with whether secinfo is present for the disk, and it's of AES type.
And for reference, below is the conversation libvirt and the qemu monitor were having before this patch, including the XML. Since libvirt wasn't adding the scsi0-0-0-1-secret0 object, it all failed rather miserably.
2016-10-07 14:09:40.974+0000: 13608: info : qemuMonitorIOWrite:534 : QEMU_MONITOR_IO_WRITE: mon=0x7f7c00eb60 buf={"execute":"human-monitor-command","arguments":{"command-line":"drive_add
dummy file=rbd:volumes/volume-e51d02fc-7399-4e51-bdde-84577ba79990:id=nova:auth_supported=cephx\\;none:mon_host=10.10.0.101\\:6789\\;10.10.0.111\\:6789\\;10.10.0.112\\:6789,file.password-secret=scsi0-0-0-1-secret0,format=raw,if=none,id=drive-scsi0-0-0-1,serial=e51d02fc-7399-4e51-bdde-84577ba79990,cache=none"},"id":"libvirt-14"}
2016-10-07 14:09:40.987+0000: 13608: info : qemuMonitorIOProcess:429 : QEMU_MONITOR_IO_PROCESS: mon=0x7f7c00eb60 buf={"return": "No secret with id 'scsi0-0-0-1-secret0'\r\n", "id": "libvirt-14"} len=79
for this XML:
<disk type="network" device="disk"> <driver name="qemu" type="raw" cache="none"/> <source protocol="rbd" name="volumes/volume-e51d02fc-7399-4e51-bdde-84577ba79990"> <host name="10.10.0.101" port="6789"/> <host name="10.10.0.111" port="6789"/> <host name="10.10.0.112" port="6789"/> </source> <auth username="nova"> <secret type="ceph" uuid="some-uuid..."/> </auth> <target bus="scsi" dev="sdb"/> <serial>e51d02fc-7399-4e51-bdde-84577ba79990</serial> </disk>
Thanks, Gema
OK thanks for confirming my suspicion... I'd like to add/merge the attached to this patch. Essentially it's a test that uses XML like above. Although it's added to the qemu_command processing - it shows the need to have the SCSI hotplug code to also have the secret processing. I still haven't figured out those hotplug tests - if you want to take a shot, be my guest! Just let me know and I'll merge it with yours and push. Thanks and congrats on your first libvirt patch! John
participants (2)
-
Gema Gomez -
John Ferlan