Re: [Xen-devel] qemu and xl semantics

[Christoph Egger <Christoph.Egger@xxxxxxx>]

On Friday 17 December 2010 11:32:41 Ian Campbell wrote:
> On Fri, 2010-12-17 at 09:49 +0000, Christoph Egger wrote:
> > On Friday 17 December 2010 10:15:14 Ian Campbell wrote:
> > > On Fri, 2010-12-17 at 09:00 +0000, Christoph Egger wrote:
> > > > Hi!
> > > >
> > > > When I start a guest with xm  the disk startup script assigns a
> > > > loopback device for qemu to open it.
> > > >
> > > > Now it seems that qemu opens the disk image directly. Then when
> > > > the loopback device wants to open the disk image then that fails
> > > > with EBUSY.
> > >
> > > By "Now..." you mean "With xl..." ?
> >
> > no, I mean with xm.
>
> Hrm, I didn't think xm had changed in this area for ages, but I don't
> really keep an eye on xm/xend.

It is not xm/xend that changed. It is qemu that changed and
the startup scripts need an adaption to the new behaviour.
Hence I am asking for the new semantics to know how to do that.

> > > > How is the disk startup script supposed to work with the new
> > > > semantic for
> > > > a) HVM guests
> > > > b) PV guests
> > > > ?
>
> I don't think there are new semantics with xm, you aren't talking about
> xl here?
>
> Can you identify a change to xend which you think changed the semantics?

See above.

> > > I think this is all very specific to the precise disk type you have in
> > > your config, i.e. tap: vs file: vs phy: etc. Which are you using?
> >
> > I use 'file'.
>
> If you are using xm and not xl this is not relevant but:
>
> AIUI libxl treats file: as tap:aio:, in other words it will fire up
> blktap to provide the device backend. xend probably used a loop device
> and treated it more like phy: i.e. invoked blkback.

Yes, I noticed that and I wonder how the algorithm works behind that.

> Since NetBSD doesn't have blktap perhaps libxl needs to be updated to do
> the NetBSD equivalent? (I thought I'd seen a patch from you which did
> this?)

The disk access works on NetBSD - don't ask me how - otherwise I wouldn't
be able to boot a guest at all. I have to run the network script manually
in the dom0 to have network access from and to the guest.

> Recently libxl was also changed to use the qemu disk backend in cases
> where blktap is not available -- perhaps that had an undesired knockon
> effect on NetBSD?

Yes. Recently this message appears from the NetBSD disk backend driver:

xbdback backend/vbd/1/832: can't VOP_OPEN device 0xe13: 16
16 means EBUSY.

> Further to this there was a patch floating around (from Stefano) which
> ensured that a qemu was launched when it was necessary for PV guests to
> provide the disk backend. I'm not sure this got merged but ion the
> meantime the workaround is to add a vfb which also causes qemu to get
> launched for a PV guest.

What is the longterm solution?

> > > > The network startup script adds the tap device to the bridge
> > > > or assigns an ip address.
> > > > With xl neither the disk nor the network script runs.
> > > > So when I start the guest with xl then I have
> > > > the tap device assigned to the guest but the
> > > > tap device is not configured in the dom0.
> > > >
> > > > How does the 'xl' way work in respect to the network script
> > > > used with 'xm' ?
> > >
> > > On Linux these are run from the hotplug event, via the udev rules. I
> > > presume you are talking about on NetBSD though?
> >
> > Yes.
> >
> > > Under Linux I think it was always the same under xm too although there
> > > have been some tweaks recently, e.g. the vif script is now always
> > > /etc/xen/scripts/vif-setup which handles the indirection to the script
> > > in the domain config or the default. Previously xend the hotplug rules
> > > called the configured script directly. This change was
> > > 21549:8bcaec29574e and was common to xm and xl I think.
> >
> > On NetBSD a xenbackendd starts along with xenstored.
> > xenbackendd watches on /local/domain/0/backend
> > and invokes the corresponding scripts when something changes
> > beneath that.
> >
> > 'xend' is doing that in DevController.py. Since 'xl' is not interacting
> > with 'xend' the scripts don't get launched at all.
>
> xl also creates stuff under /local/domain/0/backend (as it must) so why
> is xenbackendd not firing up and running the scripts?

xenbackendd is firing up for things 
like '/local/domain/0/backend/console/1/0/script'.

xenbackendd listens for changes on vec[XS_WATCH_PATH]/state.
Then it reads vec[XS_WATCH_PATH]/hotplug-status.

And then it looks at '/local/domain/0/backend/vbd' 
and '/local/domain/0/backend/vif' and starts the corresponding
scripts.

> Perhaps xenbackendd is expecting some additional key which xend adds but
> libxl doesn't?

Maybe. Is something missing from above?

Christoph

> I think this needs someone to debug from the NetBSD side, it's possible
> libxl will need to be tweaked to work properly with xenbackendd or vice
> versa.
>
>
> Ian.



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


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