Re: [Xen-devel] Driver domains and hotplug scripts, redux

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 5 Jan 2012, Ian Jackson wrote:
> Roger Pau Monn�?�© writes ("Re: [Xen-devel] RFC: Still TODO for 4.2?"):
> > I don't know much about driver domains, but from what I've read they
> > should be running something like NetBSD xenbackend and listen for
> > xenstore events. Most of the functions that I've written on my hotplug
> > series can be used to create a little daemon, that's not the problem,
> > the problem is what can we use to synchronize hotplug script calling
> > and libxl (what comes to mind is using a dedicated xenstore variable
> > for each device, but someone might have a better idea).
> 
> This envisages devicer setup/teardown scripts in driver domains
> running in a different way to those in the same domain as the
> toolstack.  Are we sure this is a good idea ?
> 
> I think it would be preferable to have only one interface to device
> scripts, which is used everywhere.  That interface would have to
> involve initiation by the toolstack, and collection of resulting
> success/failure/etc., via xenstore.
> 
> The sequence of events for vifs with a kernel-level backend needs
> to go like this:
>   * toolstack tells backend domain to create vif, via xenstore
>   * backend kernel creates a virtual network interface vifNN
>   * something in backend domain notices that this vifNN
>     has appeared and consequently
>   * device setup script runs, enslaves vifNN to bridge, adds
>     it to routing tables, gives it an address, etc.
>   * something in backend domain domain tells toolstack vif is ready
>   [ device is used ]
>   * toolstack tells backend domain to destroy vif; perhaps entire
>     xenstore directory is forcibly removed??
>   * backend kernel removes virtual network interface immediately
>     and all routes, bridge enslavements, etc., are undone
>   * something in backend notices the removal
>   * device teardown script may need to remove eg firewall rules
>   * when this is complete, the backend domain notifies the
>     toolstack (how??)
> 
> For block devices with a kernel-level backend:
>   * toolstack tells backend domain to create vbd
>     parameters include: vbd number, target??, script??
>   * something in backend domain notices this and consequently
>   * device setup script runs, creates a suitable actual
>     block device in backend domain
>   * backend kernel picks up actual block device details and
>     becomes available to guest
>   * something in backend domain tells the toolstack all is well
>   [ device is used ]
>   * toolstack tells backend domain to destroy vbd; perhaps entire
>     xenstore directory is forcibly removed??
>   * backend kernel removes its actual backend and closes the
>     block device, and somehow notifies userspace when this
>     is done so that
>   * device teardown script cleans up, including making actual
>     block device go away (if it was one which the setup script
>     created)
>   * when this is complete, the backend domain notifies the
>     toolstack (how??)
> 
> For block devices with a user-level backend:
>   * toolstack tells backend domain to create vbd
>     parameters include: vbd number, target??, script??
>   * userland backend notices this, does its housekeeping
>     and setup, and tells the toolstack all is well
>   [ device is used ]
>   * toolstack tells backend domain to destroy vbd; perhaps entire
>     xenstore directory is forcibly removed??
>   * userland backend removes its actual backend and closes the
>     resources it was using, and
>   * notifies the toolstack (how??)
> 
> Much of this seems to be covered by, or coverable by, the existing
> xenstore protocol.  I think we just need to define in more detail
> exactly how it should all work, and on each platform how the
> "something"s work.
 
I have given some thoughts on this issue and these are my observations:

- given that the backend might be in userspace, it is recommendable not
to rely on udev for the execution of the scripts;

- given that some complex network storage solutions might have difficult
timing requirements, it is advisable not to tight the execution of the setup
script to the setup of the block backend node on xenstore (that can
cause the block backend to run before its time). We want to be able to
setup the storage and once that is done write the params node on
xenstore for the block backend.

- same for teardown: it is better not to tight the executing of the
teardown block script to the removal of the block backend node on
xenstore. We could run the script independently and store their
information somewhere else.

As a consequence I suggest that we adopt a solution similar to
xenbackendd, however rather than reacting to the backend creation on
xenstore, it should react on different, more explicit, events on another
xenstore location.
This way the toolstack can decide exactly when the script gets executed
independently from the block/network backend.
Also storing the script info on a different location has the advantage
that we can prevent the script from writing (maybe even reading) to the
backend nodes on xenstore, that frankly is quite scaring.

However to do this we probably need to change some/most of/all the
scripts.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel