Re: [Xen-devel] Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Sat, 2011-10-29 at 06:57 +0100, jim burns wrote:
> Setup:
> 
> Fedora 15, w/f16's 3.1.0 (also tried 2.6.40 & 3.0.0)
> xen 4.1.2 (newly upgraded from 4.1.1, from rawhide)
> 
> Since the release notes for 4.1.2 said, in part:
> 
> Fixes/features include:
>  * New XL toolstack
> 
> I decided to test some problems I saw using xl to start a winxp hvm domu 
> under 
> xen 4.1.1, and found that they were still there, and I came up with a 
> somewhat 
> more serious one as well. I'm sure that others can point out more serious 
> problems, but these are the ones that affect me. In all cases, 'xm create' 
> does not have these problems. Domu config at the end of the post.
> 
> New to 4.1.2:
> 
> 1) Starting winxp with xl does not create a vif interface - only a tap one. 
> More exactly, the vif is created, but does not get an ipv6 address - it shows 
> up in 'ifconfig -a', or 'ifconfig vifn.0' - and does not get added to the 
> bridge. If you are using James' GPLPV drivers, you end up with no network 
> connectivity, as they use vif, not tap. I'd be surprised if other pvhvm 
> solutions don't see this also.

I see this with the tip of xen-4.1-testing too but not with
xen-unstable. I'll see if I can figure out which backport is missing...

[...]
> 2) If your vif= line in your config specifies a bridge, such as 
> 'bridge=virbr0', the '-net tap' option to qemu-dm remains as 'bridge=xenbr0', 
> as if it was hard coded. Again, this is an hvm problem. 'xl create'-ing a pv 
> domu correctly puts the vif on the requested bridge. (If memory serves, under 
> xen 4.1.1, when the vif for an hvm domain was being put on a bridge, I 
> believe 
> it was on the bridge requested, so the problem is just with tap.)

Similarly I can reproduce this too but only on 4.1.

> 3) Specifying vncviewer=1/vncconsole=1 in your config (don't remember which 
> works - I use both) will automatically start a vnc viewer for you when you 
> 'xm 
> create' an hvm domain. (Sadly, this never worked for a pv domain. You have to 
> use the xm/xl vncviewer domainname command.) This does not work with 'xl 
> create'.

I think this is just a missing feature.

> 
> 4) The 'localtime=1' option in your config is ignored by xl. This works with 
> xm. Xl will still honor the rtc_timeoffset option.

This option is supposed to control the setting of the RTC to localtime
vs UTC? Another missing feature.

If you fancy having a stab at either of these (I thing they will be
relatively simple to fix) then I'm happy to give some guidance (modulo
going to the airport in a few hours to head out to XenSummit Asia).

> 5) Anything other than 'videoram=4' in your config will be ignored when 
> starting with xl, but not with xm. You will get an error in your qemu-dm log 
> file of the form:
> 
> -videoram option does not work with cirrus vga device model. Videoram set to 
> 4M.

I'm not sure what's going on here, since this appears to be a qemu thing
and that is the same for xend and xl. Perhaps they are choosing
differing graphics card device models? How do the command lines differ
if you use this option?

> 
> So, are these bugs? or features? Certainly, I see 1) and 2) as bugs.
> 
> The rest of the qemu-dm log is unremarkable. My config follows, with 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 = "768"
> uuid = "6c7de04e-df10-caa8-bb2a-8368246225c1"
> #ostype = "hvm"
> 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
> 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=[ 'file:/windows/C/var/lib/xen/images/winxp.sav,ioemu:hda,w', 
> 'phy:/dev/cdrom,hdc:cdrom,r' ]
> #disk=[ 'file:/var/lib/xen/images/winxp,ioemu: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 = xenbr0, 
> model=rtl8139' ]
> #vif = [ 'mac=00:16:3e:23:1d:36, type=ioemu, script=vif-bridge, bridge = 
> xenbr0, model=e1000' ]
> #vif = [ 'mac=00:16:3e:23:1d:37, type=netfront, script=vif-bridge, bridge = 
> eth0' ]
> #
> 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"
> # 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=""
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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