[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Handling iSCSI block devices (Was: Driver domains and device handling)
On 13/12/12 19:23, Ian Jackson wrote: > 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. According to RFC3270 and RFC1035 IQNs should follow this format: iqn.yyyy-mm.com.example:optional.string The problem is that Open-iSCSI seems to accept almost anything, for example iqn.yyyy-mm,com@example:... is a valid iqn from Open-iSCSI point of view. The only character that Open-iSCSI doesn't seem to accept in iqns is "/", but I don't really like using that as a field separator inside of target. So I propose the following encoding for target: "<iqn>,<portal>" "<iqn>,<portal>,<auth_method>,<user>,<password>" If a user/password is given, we should take care about what we write to "params" xenstore backend field (because the DomU can read that). Would you agree with the syntax described below? >> 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. Yes, it might be better to specify the script. >> 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. I like the approach to call the same hotplug script twice, the first time use something like `/etc/xen/scripts/block-iscsi prepare`, and the second time `/etc/xen/scripts/block-iscsi add` _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |