Re: [Xen-devel] Re: xl vs. xm, possible bug in xl

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 9 Sep 2011, Sven KÃhler wrote:
> Am 09.09.2011 14:05, schrieb Stefano Stabellini:
> > 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:
> 
> Thanks, sounds like this will fix my problem.
> 
> Is there any chance that this is going to be in 4.1.2 final?

I think it should be!

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