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