| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] qemu and xl semantics
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
|
|
|
| |
|
Home