Re: [PATCH] support auth for qemu SCSI hotplug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]