[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)
On Tue, Jul 26, 2011 at 06:20:43PM -0400, jim burns wrote: > 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'.) > Interesting. Have others seen this problem? I don't think vfb-line is supposed to be needed with HVM guests.. > 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. > Yep. -- Pasi > 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-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |