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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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 ?

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

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