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

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

On 14/12/12 13:30, Ian Jackson wrote:
> Roger Pau Monne writes ("Re: Handling iSCSI block devices (Was: Driver 
> domains and device handling)"):
>> 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?
> 
> Wouldn't it be better to specify this in a more key/value like way ?

I guess we could use something like:

"<iqn>,<portal>,auth_method=<auth_method>,user=<user>,password=<password>"

Where <iqn> and <portal> are required, and all other fields are
optional. Password should always be the last field, because it can
contain special characters, like "," or "=".

> The password is a problem.  Perhaps we need to arrange not to write
> params to a place where the guest can see it, but that means upheaval
> for the interface to block scripts.

I was thinking of adding a new variable to aodev that can contain an
extra parameter to pass to hotplug scripts, so we can directly pass the
full diskspec to the hotplug script and the hotplug script itself can
decide what to save in the "params" field (to be used later in the
shutdown/destroy).

>>> 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`
> 
> So how would we tell whether the script understood this ?

I'm still looking into the current hotplug script mess, but I only see
the following lines in block-common.sh that should be changed:

if [ "$command" != "add" ] &&
   [ "$command" != "remove" ]
then
  log err "Invalid command: $command"
  exit 1
fi

I think current block hotplug scripts will work nicely when passed the
"prepare" command, they will become no-ops, since they all seem to use
the following case:

case "$command" in
add)
        [...]
        ;;
remove)
        [...]
        ;;
esac

> Perhaps we should invent a new config parameter parallel to script
> which specifies an entirely new interface.
> 
> Ian.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel