The vmware driver doesn't currently use auth information passed to it by cinder when attaching an iSCSI volume. I'm working on a patch to address this.
Adding authentication to the existing code is relatively simple. However, in going over the code I've noticed a problem. The code assumes that the host has a software iSCSI hba configured[1]. Simplifying slightly: it adds a new target to the hba and maps this to the VM as a RDM. The problem is that it only operates on the host returned by vm_util.get_host_ref(). This is the first host returned by a query, so can be thought of as random. This presents an immediate problem because the VM isn't guaranteed to run on this host. I had hoped that the cluster might be able to move config automatically between software HBAs, but I can confirm that vMotion certainly does not work if only 1 software HBA is configured with the target. I haven't yet confirmed that it does work if both hosts are configured with the target. I assume it does, because otherwise guests with iSCSI storage would be very much second class citizens in a cluster. Assuming it does, we need to ensure that all hosts in the cluster are configured with all iSCSI targets. Note that this isn't just at the time the target is added, either. If a new host is added to the cluster, we must ensure that all iSCSI targets present in the cluster are added to it automatically. If we don't do this, at the very least DRS won't work. Note that DRS can initiate vMotion at any time, so this can't be tied to an api action. Do we currently do any kind of cluster maintenance along these lines? This has also lead me to thinking about vm_util.get_host_ref(). If the host it returns is powered off, any attempt to manipulate it will fail. This definitely breaks the current iSCSI code, but I suspect it breaks a bunch of stuff. I can't help but feel that the api is itself broken, and we should re-examine everywhere it is used to better do something else. Matt [1] Incidentally, I had wanted to automatically add one of these if it wasn't present, but after scouring the api I'm not convinced it's possible. -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev