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

[John Ferlan]

>>   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 :-(
> 

Ahh.. hmm... Trying to figure out how the matching is done wasn't
completely clear... Going with the full IQN path seemed to work, but
yeah I have a single iSCSI server.

Although I have to wonder how multiple servers in the same domain would
be handled today from libvirt since without providing the '-iscsi' arg,
it seems qemu will create the default IQN
"iqn.2008-11.org.linux-kvm%s%s", where the %s%s could be ":name" or
empty depending on the uuid_info. I assume that wouldn't change
regardless of the number of iSCSI -drive's provided in the libvirt XML.
So, if each -drive used a unique iSCSI server, then I wonder if it would
work "today".

<sigh> I'll adjust and repost patch 8 without iSCSI code. We can at
least take advantage of RBD.  I can drag in patch 7 to that in order to
better handle the qemuDomainSecretHaveEncrypt

John