[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Roger Pau Monne writes ("Handling iSCSI block devices (Was: Driver domains and 
device handling)"):
> [stuff]

Most of this sounds sensible.

> 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

Are we suggesting that every backend type should be able to define its
own parameters ?  I was imagining that these options would all go into
"target" - and if "target" is last it can contain commas and =s.

> 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.

I don't think this is right.  I think the right answer is
"script=iscsi".  The format might be qcow or something.

> 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"?

Clearly when we have this two-phase setup we need to have more
scripts, or the existing script with different arguments.

I think it should be controlled by the same argument.  So maybe
script=iscsi causes libxl to check for a dropping in the script file
saying "yes do the prepare thing" or maybe it runs
/etc/xen/scripts/block-iscsi--prepare or something.

Ian.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.