[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |