Re: [PATCH v2 13/13] tools: don't stop xenstore domain when stopping dom0

[Ian Campbell <ian.campbell@citrix.com>]

On Thu, 2016-01-07 at 07:52 +0100, Juergen Gross wrote:
> On 06/01/16 17:33, Ian Campbell wrote:
> > On Fri, 2015-12-18 at 15:53 +0100, Juergen Gross wrote:
> > > On 18/12/15 15:42, Andrew Cooper wrote:
> > > > On 18/12/15 13:14, Juergen Gross wrote:
> > > > > When restarting or shutting down dom0 the xendomains script tries
> > > > > to
> > > > > stop all other domains. Don't do this for the xenstore domain, as
> > > > > it
> > > > > might survive a dom0 reboot in the future.
> > > > > 
> > > > > The same applies to xl shutdown --all.
> > > > > 
> > > > > Signed-off-by: Juergen Gross <jgross@suse.com>
> > > > > ---
> > > > >  tools/hotplug/Linux/xendomains.in | 17 +++++++++++++++++
> > > > >  tools/libxl/xl_cmdimpl.c          | 19 +++++++++++++++----
> > > > >  2 files changed, 32 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/tools/hotplug/Linux/xendomains.in
> > > > > b/tools/hotplug/Linux/xendomains.in
> > > > > index dfe0b33..70b7f16 100644
> > > > > --- a/tools/hotplug/Linux/xendomains.in
> > > > > +++ b/tools/hotplug/Linux/xendomains.in
> > > > > @@ -196,6 +196,17 @@ rdnames()
> > > > >      done
> > > > >  }
> > > > >  
> > > > > +# set xenstore domain id (or 0 if no xenstore domain)
> > > > > +get_xsdomid()
> > > > 
> > > > A get/set mismatch.
> > > 
> > > Hmm, depends.
> > > 
> > > It is getting the domid of the xenstore domain and is setting
> > > XS_DOMID accordingly. The main semantics are to get the correct
> > > domid.
> > > 
> > > > 
> > > > > +{
> > > > > +    ${bindir}/xenstore-exists /tool/xenstored/domid
> > > > > +    if test $? -ne 0; then
> > > > > +        XS_DOMID=0
> > > > > +    else
> > > > > +        XS_DOMID=`${bindir}/xenstore-read /tool/xenstored/domid`
> > 
> > Please update docs/misc/xenstore-paths.markdown with this.
> 
> Okay.
> 
> > 
> > Did you mean /tools?
> 
> No. The xenstore path is /tool/...

You mean that are preexisting uses of this path?

/me looks.

Oh, so there is. Undocumented too :-(

> > 
> > Earlier in the series there was a patch which looped over xc_dom_info
> > looking for the xs domain -- if this is in xenstore can't it use that?
> 
> Hen and egg problem. You need to know how to connect to xenstore
> (domain or daemon) before being able to read xenstore.

Oh, of course.

Can you not infer from the presence of absence of the sockets in the local
f/s or do they always exist (i.e. stale from a previous configuration)?

We did once try switching to always using the domain ring, even if the
client and server were co-located in the same domain, but that can result
in uninterruptible sleeps in the kernel IIRC (a bug which might have since
been fixed, not sure). Anyway, that probably rules out the "solution" of
always using the domain.

The daemon would drop a pid file, but I suppose that might also be stale.

I'm mostly just brainstorming here, I don't really have a problem with the
scan in the earlier patch.

(FWIW in English idiom we usually say chicken and egg BTW)

Ian.

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