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

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

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