From: jim burns <jim_burn@bellsouth.net>
To: xen-devel@lists.xensource.com
Cc: xen-users@lists.xensource.com
Subject: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)
Date: Sat, 29 Oct 2011 01:57:12 -0400 [thread overview]
Message-ID: <1758215.SCbitK4oVy@dell4550> (raw)
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=""
next reply other threads:[~2011-10-29 5:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-29 5:57 jim burns [this message]
2011-10-29 6:17 ` Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV) jim burns
2011-10-31 10:56 ` Ian Campbell
2011-10-31 10:50 ` Ian Campbell
2011-10-31 11:26 ` Ian Campbell
2011-10-31 23:00 ` jim burns
2011-11-01 12:49 ` Ian Campbell
2011-11-01 19:52 ` jim burns
2011-11-03 6:46 ` Stefano Stabellini
2011-11-03 8:39 ` Re: [Xen-devel] " Flavio
2011-11-03 23:33 ` [Xen-users] " Ian Campbell
2011-11-04 1:24 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1758215.SCbitK4oVy@dell4550 \
--to=jim_burn@bellsouth.net \
--cc=xen-devel@lists.xensource.com \
--cc=xen-users@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.