[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: xl vs. xm, possible bug in xl
CC'ing IanJ to make sure he is going to read this On Fri, 9 Sep 2011, Stefano Stabellini wrote: > On Fri, 9 Sep 2011, Sven KÃhler wrote: > > Am 09.09.2011 13:27, schrieb Stefano Stabellini: > > >> Any clue, that the second problem is about? > > >>> # xl create /etc/xen/xen-sk1 > > >>> Parsing config file /etc/xen/xen-sk1 > > >>> libxl: error: libxl_device.c:476:libxl__wait_for_device_model Device > > >>> Model not ready > > >>> xl: fatal error: libxl_create.c:535, rc=-1: > > >>> libxl__confirm_device_model_startup > > > > > > That means that qemu failed to start. Could you please cat > > > /var/log/xen/qemu-dm-domainname.log? > > > > There is no such file (my domain config lacks a name="something" line). > > However qemu-dm-test.log does exist and is of recent date, and it says > > that qemu cannot be started. This is very plausible, since qemu is not > > even installed. This machine is supposed to start paravirt guests only. > > And xen has been compiled without support for hvm guests. (Not sure > > right now, what the gentoo people do to disable support support for hvm > > guests). > > > > Does my config file for the domain (see one of my previous emails in > > this thread) indicate, that the machine is a hvm domain? How can I tell > > xl that this a paravirt domain, and qemu is not needed and should not be > > used? > > I think I have found the issue: if blktap2 is not enabled xl is going to > start qemu (to provide a disk backend) even if it is not actually needed > because the user wants to use blkback. > > We have a patch upstream to fix this issue but it hasn't been backported > to 4.1: > > > > # HG changeset patch > # User Ian Campbell <ian.campbell@xxxxxxxxxx> > # Date 1300213187 0 > # Node ID d4ca456c0c25c3c3daedc216c657296f2895482a > # Parent 3caed2112c65791855e8bf0fd34c15e3160bbc78 > libxl: do not start a xenpv qemu solely for tap devices if blktap is available > > qemu is used as a fallback for DISK_BACKEND_TAP if no blktap is > available but if blktap is available, or for DISK_BACKEND_PHY, we > don't need a qemu process. > > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> > Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> > Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> > > diff -r 3caed2112c65 -r d4ca456c0c25 tools/libxl/libxl_dm.c > --- a/tools/libxl/libxl_dm.c Tue Mar 15 10:14:27 2011 +0000 > +++ b/tools/libxl/libxl_dm.c Tue Mar 15 18:19:47 2011 +0000 > @@ -828,8 +828,29 @@ int libxl__need_xenpv_qemu(libxl_ctx *ct > goto out; > } > > - if (nr_disks > 0 && !libxl__blktap_enabled(&gc)) > - ret = 1; > + if (nr_disks > 0) { > + int blktap_enabled = -1; > + for (i = 0; i < nr_disks; i++) { > + switch (disks[i].backend) { > + case DISK_BACKEND_TAP: > + if (blktap_enabled == -1) > + blktap_enabled = libxl__blktap_enabled(&gc); > + if (!blktap_enabled) { > + ret = 1; > + goto out; > + } > + break; > + > + case DISK_BACKEND_QDISK: > + ret = 1; > + goto out; > + > + case DISK_BACKEND_PHY: > + case DISK_BACKEND_UNKNOWN: > + break; > + } > + } > + } > > out: > LIbxl__free_all(&gc); _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |