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

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



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.

To be clear, 'xm create winxp' correctly puts vif on the bridge, nor did xl 
have this problem under xen 4.1.1. Also, this is an hvm problem. 'xl create'-
ing a pv domu correctly puts the vif on a bridge.

For the remaining problems, note that 'xl create winxp' creates a qemu-dm 
process with the following parameters:

qemu-dm -d 8 -domain-name winxp -vnc 0.0.0.0:3 -k en-us -serial pty -videoram 
4 -boot cda -usb -usbdevice tablet -soundhw es1370 -acpi -vcpus 2 -vcpu_avail 
0x3 -net nic,vlan=0,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net 
tap,vlan=0,ifname=tap8.0,bridge=xenbr0,script=no -M xenfv

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.)

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'.

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

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.

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


 


Rackspace

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