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
|
Home