[Xen-API] Handling iSCSI block devices (Was: Driver domains and device handling)

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

After doing some more research I'm able to understand a little better
how the Open-iSCSI initiator works (which I think is the most common
initiator in the Linux world, and should be supported by all distros).
This is marginally derived from the driver domains protocol proposal,
because if we are going to implement a driver domain protocol we should
try to handle device kinds that can have a two phase connection
mechanism, and iSCSI looks like the most interesting candidate (from my
POV).

I would like to implement iSCSI support in libxl to have at least a
device kind that makes use of this two phase connection mechanism, and
then draft a driver domain communication protocol, since we will already
have a device that needs this kind of protocol (it looked strange to
implement a two phase protocol without having any device that needed it).

This is the very simple scheme of the two phases of the connection of a
iSCSI device:

The first phase of connecting a iSCSI device consists of discovering it,
which can be done before entering the blackout phase of migration:

iscsiadm -m discovery -t st -p <ip>:<port>

And possibly setting the right authentication method:

iscsiadm -m node --targetname <iqn> -p <ip>:<port> --op=update --name
node.session.auth.authmethod --value=<auth_method>
iscsiadm -m node --targetname <iqn> -p <ip>:<port> --op=update --name
node.session.auth.username --value=<user>
iscsiadm -m node --targetname <iqn> -p <ip>:<port> --op=update --name
node.session.auth.password --value=<password>

The second phase is the actual device plug:

iscsiadm -m node --targetname <iqn> -p <ip>:<port> --login

I'm trying to fit all this parameters in the current diskspec, but I
guess we will have to add new parameters. I think the iqn parameter
should go in "target", and the rest should have their own parameters, so
this will leave us with the following new parameters:

- portal: specifies the address, and optionally the port to connect to
the desired target, the format is <ip>:<port>
- authmethod: authentication method
- user: username to use for authentication
- password: password to use for authentication.

So the diskspec line would look like:

portal=127.0.0.0:3260, authmethod=CHAP, user=foo, password=bar,
backendtype=phy, format=iscsi, vdev=xvda,
target=iqn.2012-12.com.example:lun1

Note that I've used the format parameter here to specify "iscsi", which
will be a new format, to distinguish this from a block device that also
uses the "phy" backend type. All this new parameters should also be
added to the libxl_device_disk struct.

Since this device type uses two hotplug scripts we should also add a new
generic parameter to specify a "preparatory" hotplug script, so other
custom devices can also make use of this, something like "preparescript"?

I would like to get some feedback about handling iSCSI devices, and also
about adding all this new parameters to the diskspec.

Thanks, Roger.

_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api