> 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