[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?


Regards,
  Sven

Attachment: signature.asc
Description: OpenPGP digital signature

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.