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

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

On 14/12/12 16:46, Ian Jackson wrote:
> Roger Pau Monne writes ("Re: Handling iSCSI block devices (Was: Driver 
> domains and device handling)"):
>> 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).
> 
> That's all very well but command line parameters are visible in ps and
> so not suitable for passwords.  Really there should be an area in
> xenstore that's for communication between the toolstack and the driver
> domain (including scripts in the latter), but which is not visible to
> the guest.
> 
>>> 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" ]
> 
> What about existing out-of-tree scripts ?  Do they all use
> block-common ?
> 
>> then
>>   log err "Invalid command: $command"
>>   exit 1
>> fi
> 
> And this is no good because if libxl does the error handling properly
> it would cause every attempt to fail :-).  You could explicitly ignore
> prepare and unprepare.
> 
>> 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:
> 
> I'm worried about out-of-tree scripts.
> 
> 
> The existing hotplug script interface is pretty horrible TBH.  Which
> is why I was suggesting inventing a new one.  We could keep the old
> interface for out-of-tree and unconverted in-tree scripts, and provide
> a new parameter to request the new style.
> 
> Eg "method=<something>" rather than "script=<something>" would mean
> "set script to <something> and also set the flag saying `use the new
> script calling convention'"

Yes, I agree that current hotplug script interface is not good (if this
was ever intended to be an interface).

When method=<foo> is used as a parameter in the disk specification, it
is assumed that script <foo> is using the new hotplug calling convention

Script <foo> will be called with only one of the following parameters:

 * prepare: called before start building the domain, this is specially
interesting during migration to offload as much work as possible from
the "add" call, which is done during the blackout phase of migration. In
the prepare state, the backend xenstore entries have not yet been created.

 * add: called to connect the device. Xenstore backend entries exist,
and backend state is 2 (XenbusStateInitWait).

 * remove: called to disconnect the device. Xenstore backend entries
exists, and backend state is 6 (XenbusStateClosed).

Environment variables the script can use (set by the caller):

 * BACKEND_PATH: path to xenstore backend of the related device, ie:
/local/domain/0/backend/vbd/3/51712/. Empty when the script is called
with "prepare" argument. When the new hotplug calling convention is
used, the toolstack will not write the backend "params" node, it is up
to the hotplug script to write it if necessary.

 * HOTPLUG_PATH: path to the xenstore directory that can be used to pass
extra parameters to the script. In this implementation only the "params"
variable is set, and it will contain the full diskspec string. This
xenstore path will not be deleted until the script has been called with
the "remove" parameter, so it can be used to store information that will
persist between the different hotplug calls.

I'm not sure where HOTPLUG_PATH should reside, does
/local/domain/<backend_domid>/libxl/hotplug/<domid>/<devid>/ sound ok?

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