WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] qemu and xl semantics

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