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

[Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)



On Tue July 26 2011 1:00:27 PM Pasi Kärkkäinen wrote:
> On Tue, Jul 26, 2011 at 04:39:41PM +0100, Ian Campbell wrote:
> > On Mon, 2011-07-25 at 17:05 -0400, Pasi Kärkkäinen wrote:
> > > On Mon, Jul 25, 2011 at 04:39:16PM -0400, jim burns wrote:
> > > > On Mon July 25 2011 3:57:23 PM Pasi wrote:
> > > > 
> > > > Btw, maybe you were following the thread '[Xen-devel] Failure to
> > > > create HVM DomU at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10
> > > > (alpha 2)'.  In my fork of that thread, I summarized many other
> > > > threads over the last month of people having problems starting an
> > > > hvm domu under xen 4.1.x. Konrad finally provided the solution -
> > > > 4.1.x requires the pv style vfb= line, not the indidvidual
> > > > variables.
> > 
> > Perhaps I misunderstand this stuff but AIUI the vfb= line configures a
> > Xen PV framebuffer device whereas the individual vnc*/sdl*/etc variables
> > configure the backend for the emulated VGA device. IOW they are pretty
> > much orthogonal and (for an HVM guest) both should work (dependent on
> > the required in-guest support being available). Also I'm not sure if
> > they can be used simultaneously, I expect they can.

> Jim: Can you please post full example of working HVM cfgfile and
> not-working HVM cfgfile. (including any errors you get with the latter).

> > > > Which brings up my pet peev about documentation. Even something as
> > > > simple as updating the xmexample files in the /etc/xen tree would
> > > > have avoided this problem for so many people. Since you lurk around
> > > > in Xen Devel, maybe you can make people aware of the problem?
> > 
> > If you find areas where xm* are not accurate than patches would be very
> > much appreciated.

Sure, thanx. The following worked from xen 3.2.x to 4.0.1. w/o the vfb= line. 
Starting with xen 4.1.x, w/o the vfb= line, the vnc window immediately exits 
without even displaying the bochs bios, and qemu-dm exits also. Not till 
adding the vfb= line does qemu-dm come up properly, as in previous xen 
versions. The qemu-dm-winxp.log file is not very informative, as it basically 
doesn't change w/ or w/o the vfb= line. (Except a full guest boot adds lines 
that start with 'Unknown PV product 2' (gplpv) and end with 'Time offset'.)

The 'xen be: console-0:' errors only occur when you use 'xm create', not 'xl 
create'. You'll notice I've gone back to using a xenbr0 bridge, setup by the 
fedora (15) ifcfg- files. Xl won't put tapn.0 on the eth0 bridge, so the guest 
comes up w/o a functioning network, even tho' the vif= line previously 
explicitly set bridge=eth0. Now it specifies bridge=xenbr0. The error with 'xl 
create' and no vfb= line is even less informative. With 'xm create', xend.log 
properly reports that xen refused to restart the guest to prevent loops - 
guest is restarting too fast. With 'xl create' xl just goes into an infinite 
loop, spawning child xls and qemu-dms that immediately exit.

No where in the xmexample.hvm and similar files is vfb= mentioned. Lots of 
people over the last month have been having trouble starting their hvm 
domains, until Konrad mentioned in the thread mentioned above to add the vfb= 
line.

winxp config file: (python code commented out to keep xl happy)

#import os, re
#arch = os.uname()[4]
#if re.search('64', arch):
#    arch_libdir = 'lib64'
#else:
#    arch_libdir = 'lib'

name = "winxp"
builder='hvm'
memory = "512"
uuid = "6c7de04e-df10-caa8-bb2a-8368246225c1"
#ostype = "hvm" (no longer needed?)
on_reboot = "restart"
on_crash = "restart"
on_poweroff = "destroy"
vcpus = "2"
viridian=1
#
#kernel = "/usr/lib/xen/boot/hvmloader"
kernel = "hvmloader"
acpi=1
apic=1
boot= "cda"
# New stuff
#device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
#device_model = '/usr/lib/xen/bin/qemu-dm'
device_model = 'qemu-dm'
#
keymap='en-us'
localtime=1
#rtc_timeoffset=-14400
#rtc_timeoffset=-18000
pae=1
serial='pty'
#serial = "/dev/ttyS0"
#   enable sound card support, [sb16|es1370|all|..,..], default none
soundhw='es1370'
# enable stdvga, default = 0 (use cirrus logic device model)
#stdvga=1
videoram=4  # also necessary to keep xl happy, even tho the default is 8
stdvga=0
#usbdevice="mouse"
usbdevice="tablet"
xen_extended_power_mgmt = 0
#
#disk=[ 'tap2:aio:/var/lib/xen/images/winxp,hda,w', 
'phy:/dev/cdrom,hdc:cdrom,r' ]
disk=[ 'phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
b1f2-b4799d15e4cd-lun-1,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]
#
#vif = [ 'mac=00:16:3e:23:1d:36, script=vif-bridge, bridge = eth0' ]
vif = [ 'mac=00:16:3e:23:1d:36, type=ioemu, script=vif-bridge, bridge = 
xenbr0' ]
#
sdl=0
vfb = [ 'vnc=1, vnclisten=0.0.0.0, vncunused=0, vncdisplay=3, vncpasswd= ']
vnc=1
vnclisten="0.0.0.0"
#vnclisten="192.168.1.0" ( is there any way to do this? use to work in xen 
3.2)
# set VNC display number, default = domid
vncdisplay=3
# try to find an unused port for the VNC server, default = 1
vncunused=0
vncviewer=1
vncconsole=1
monitor=1
vncpasswd=""

qemu-dm-winxp.log:

domid: 1
config qemu network with xen bridge for  tap1.0 xenbr0
Using file /dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
b1f2-b4799d15e4cd-lun-1 in read-write mode
Using file /dev/cdrom in read-only mode
Watching /local/domain/0/device-model/1/logdirty/cmd
Watching /local/domain/0/device-model/1/command
Watching /local/domain/1/cpu
char device redirected to /dev/pts/5
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 6c7de04e-df10-caa8-bb2a-8368246225c1
Time offset set 72000
char device redirected to /dev/pts/6
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw 
state.
xs_read(/local/domain/0/device-model/1/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error. /vm/6c7de04e-df10-caa8-
bb2a-8368246225c1/vncpasswd.
medium change watch on `hdc' (index: 1): /dev/cdrom
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
vcpu-set: watch node error.
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xs_read(/local/domain/1/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/1/log-throttling'
medium change watch on `/local/domain/1/log-throttling' - unknown device, 
ignored
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
cirrus vga map change while on lfb mode
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw 
state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro 
state.
Unknown PV product 2 loaded in guest
PV driver build 1
region type 1 at [c100,c200).
region type 0 at [f3001000,f3001100).
squash iomem [f3001000, f3001100).
Time offset set -14400, added offset -86400
Time offset set -14398, added offset 2
Time offset set 2, added offset 14400
Time offset set 1, added offset -1

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


 


Rackspace

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