Re: [Xen-devel] Fwd: Re: [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-04-26 at 14:02 +0100, Ian Jackson wrote:
> Thanks for your reply.  I see you didn't reply to all of my comments.
> Do you plan to address the others later ?
> 
> Roger Pau Monne writes ("Fwd: Re: [Xen-devel] [PATCH v3 3/5] libxl: call 
> hotplug scripts from libxl for vbd"):
> > Ian Jackson escribiÃ:
> > > So we no longer have any function which will synchronously and
> > > immediately destroy a domain and throw away everything to do with it.
> > > Is it actually the case that you think such a function cannot be
> > > provided ?
> > 
> > It can be provided, but we should create another command or add an
> > option to "destroy" (like -f), that doesn't wait for backend
> > disconnection and just nukes both frontend/backend xenstore entries.
> > This will also prevent us from executing hotplug scripts, and could lead
> > to unexpected results.
> 
> Quite so.  But it is important to be able to disregard a
> malfunctioning driver domain.  That would make it possible to shut
> down all the guests using it, destroy the driver domain itself, and
> restart it in a hopefully good state, for example.
> 
> > With this series we wait for the backend to disconnect for 10s, and if
> > it doesn't respond we nuke the frontend and wait for another 10s. If
> > after that it fails to disconnect we nuke the remaining backend xenstore
> > entries.
> 
> I think we need to think about these timeouts.  At the very least
> they're policy which should probably not be hardcoded in libxl; and
> arguably people might want to be able to specify infinite ("I trust my
> guest or driver domain and never want to pull the rug out from under
> its feet") or zero ("this guest or driver domain has gone wrong and I
> want it killed, now").

Unless the same is going to be true of the eventual solution (which I
suppose it may well be?) we should be wary of over engineering the
interim solution for 4.2.

> > >> +# Hack to prevent the execution of hotplug scripts from udev if the 
> > >> domain
> > >> +# has been launched from libxl
> > >> +if [ -n "${HOTPLUG_GATE}" ]&&  \
> > >> +   `xenstore-read "$HOTPLUG_GATE">/dev/null 2>&1`; then
> > >> +    exit 0
> > >> +fi
> > >
> > > Oh I see.  Hmm.  Why should this string not be fixed ?  I'm not sure I
> > > like the idea of being able to pass some random other xenstore path.
> > 
> > Anyway, I will have to pass an environmental variable when calling the
> > script from udev, I can rename this to UDEV_CALL=1 if that sounds better.
> 
> Perhaps it would be better to do things the other way around, and have
> an env var for the case where we're _not_ calling the script from
> udev ?  After all, udev config is configuration (at least on my
> distros) which the user may not update when the software is updated.

It was my suggestion to do it this way so that we don't end up with a
vestigial env var which must always be set for no real reason after
we've removed the udev path altogether.

I don't really mind though, we could live with that vestigial thing, or
have another, easier, transition a few releases down the line.

Ian.


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