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

[Xen-users] Re: [Xen-devel] Failure to create HVM DomU at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10 (alpha 2)

On Sun July 17 2011 3:47:16 PM I wrote:
> According to several threads, such as mine last month - '[Xen-users]
> Working with Fedora 15 & systemd' - and  '[Xen-users] Problems
> with HVM after upgrade from 4.0.1 to 4.1.1', and a private communication
> with t.wagner in '[Xen-users] XEN-4.1.1 and linux kernel 3.0-rc5', and
> finally '[Xen-users] Re: Trouble starting HVM domU with Linux 3.0.0 and
> Xen 4.1.1',
> hvm & xen 4.1.x don't mix, either with kernel 3.0.0, or pvops 2.6.32 (which
> was working with xen 4.0.2 prior to upgrading from fedora 14 to f15, and
> xen 4.1. In the last thread mentioned above, the solution was to upgrade
> to xen 4.2 unstable. My equally effective solution was to downgrade to xen
> 4.0.2, since fedora rawhide doesn't have 4.2 yet.
> Sorry for the top post - I'm not subscribed, but I thought the summary was
> worth posting.

On 7/18, in the main fork of this thread, Konrad proposed another solution:

> I believe the xl command expects you to use 'vfb' option instead of
> the vnc and vncdisplay for 4.1

> So:

> vfb = [ 'vnc=1, vnclisten=,vncunused=1']

I can confirm that this works. In fact, my winxp config has both the 
individual variables, and a vfb= line, and both xl and xm can happily create 
my domu. This worked under xen 4.0.2, and then I reinstalled xen 4.1.1 from 
fedora rawhide (where I got 3.0.0 dom0 from), and xm/xl create still work. 
Strangely, tho', I'm still getting the error in qemu-dm-winxp.log:

> xen be: console-0: xen be: console-0: initialise() failed

xm works as well as it always did on fedora 14/xen 4.0.2, with only the 
addition of a vfb= line. This is with 3.0.0, or pvops 2.6.32 (myoung), altho' 
the unoptimized drivers in 3.0.0 make 2.6.32 the clear favorite.

xl has several problems. 'localtime=1' seems to be ignored, and a vncviewer is 
not auto-launched with vncviewer=1 or vncconsole=1. either as a separate 
variable, on in the vfb= line.

However, the major problem is xl puts the tap interface on the old style 
xenbr0 bridge, instead of the new style eth0 bridge. (Yes, I still have xend 
running - I want both systems to operate in parallel.) And the vif interface 
is created w/o an inet6 addr, so even if I manually move tap and vif to the 
eth0 bridge with brctl, my domu still comes up with no network connectivity.

Anybody found a solution to this? It probably only affects hvm domus.


Xen-users mailing list



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