[libvirt] [PATCH] support auth for qemu SCSI hotplug

[John Ferlan]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-tests-Merge-test-for-RBD-SCSI-hotplug.patch
Type: text/x-patch
Size: 4083 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161019/ba9905ee/attachment-0001.bin>