[libvirt] [PATCH v2 8/8] qemu: Utilize qemu secret objects for SCSI/RBD auth/secret

[Daniel P. Berrange]

On Mon, May 02, 2016 at 05:51:15PM -0400, John Ferlan wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1182074
> 
> If they're available and we need to pass secrets to qemu, then use the
> qemu domain secret object in order to pass the secrets for iSCSI and
> RBD volumes instead of passing plaintext or base64 encoded secrets on
> the command line.
> 
> Adjust the qemuDomainSecretHaveEncrypt API in order to check for the
> HAVE_GNUTLS_CIPHER_ENCRYPT being set as the primary decision point
> to whether an IV secret can be attempted and fall back to plain secret
> if the API is not available.
> 
> The goal is to make IV secrets the default and have no user interaction
> required in order to allow using the IV mechanism. If the mechanism
> is not available, then fall back to the current mechanism.
> 
> New API's:
>   qemuBuildSecretInfoProps: (private)
>     Generate/return a JSON properties object for the IV secret to
>     be used by both the command building and eventually the hotplug
>     code in order to add the secret object. Code was designed so that
>     in the future perhaps hotplug could use it if it made sense.
> 
>   qemuBuildSecretIVCommandLine (private)
>     Generate and add to the command line the -object secret for the
>     IV secret. This will be required for the subsequent iSCSI or
>     RBD reference to the object.
> 
>   qemuBuildiSCSICommandLine: (private)
>     Required for iSCSI since qemu only processes the "user=" and
>     "password-secret=" options for an "-iscsi" entry. At some point
>     in a future release, qemu may support those options on the -drive
>     command line for iscsi devices. The one caveat to this code is
>     rather than provide an 'id=' field for the -iscsi command, use
>     the "initiator-name=" argument since it doesn't have the same
>     restrictions regarding characters. The initiator-name is described
>     as taking an IQN, which is the path argument.

I'm not actually convinced this is doing what you think it is. AFAICT
from reading the QEMU code, the only way to associated the -drive
and -iscsi options is via the 'id' parameter of the -iscsi arg matching
the IQN of the -drive option. The 'initiator-name' does not appear to
have any effect on handling.  If 'id' doesn't match, then QEMU just
always falls back to finding the first -iscsi arg.

So IIUC with your patch here all -drive options are just going to use
the first -iscsi arg, which will be wrong when we are connecting to
several different iscsi servers.

I'm not really seeing any viable way to deal with this problem, so I
think we might need to wait for QEMU 2.7 before we can use secrets
with iSCSI :-(

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|