All of lore.kernel.org
 help / color / mirror / Atom feed
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=""

             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.