Re: [Xen-devel] qemu and xl semantics

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

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.

> > > 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?

> > 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.

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?)

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?

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.

> > > 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?

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

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.


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