|
Pls cc: me in replies, as I am not subscribed.
System is fedora 16, with rawhide xen 4.1.2, and rawhide 3.3.0-rc3 (with the debug options turned off.
I finally got stubdoms to work recently, with some minor problems. For those interested in how, I describe how after I describe the problems.
1) After my winxp hvm domu, started with a stubdom, got some windows updates yesterday, I restarted (not shutdown), and the new domain hung in pause:
root@insp6400 02/16/12 3:02AM:~
[543] > xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1052 2 r----- 17288.1
winxp 8 751 1 --p--- 0.0
'xl unpause'-ing it leaves all dashes in the State, and Time remains at 0.0
Since 'xenstore-ls /vm' lists 'winxp' as having the uuid I specified in the hvm config, this is indeed the main domain, not the stubdom, which would be called 'winxp-dm', and have Mem equal to 32.
I tried playing around with the methodology used in /usr/lib/xen/bin/stubdom.sh to create a stubdom with 'xm'. I saved the stubdom config file generated, in /etc/xen, and manually issued the 'xm create' line from stubdom.sh, substituting 'xl' for 'xm'. The original line is:
xm create -c ${stubdom_configdir}/$domname-dm target=$domid memory=32 extra="$extra" < /tmp/$domname-dm &
and with the config file:
kernel = "/usr/lib/xen/boot/ioemu-stubdom.gz"
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, bridge=xenbr0, model=e1000' ]
vfb = [ 'vnc=1, vnclisten=0.0.0.0, vncunused=1, vncdisplay=3, vncpasswd= ']
I executed:
xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8"
and only got a syntax error on the '-d'. Not that I was expecting this to work: lsof shows qemu-dm (the stubdom from a working 'xl create') has a socket and a fifo open, and I have no idea how to set this up. There are no sockets in /tmp or /var/lib/xen* that don't correspond to the startup of xend.
So my question is: is this a bug, and is it fixed in xen 4.2? Since windows restarts by itself fairly often enough, this requires manual intervention.
2) I'm having a strange problem right after I get a xen update from rawhide: stubdoms stop working for a day after wards. It happened with fedora xen 4.1.2-7 and -8. The next time it happens, I'll look at whether something in /var/lib/xen* changed.
Just to be complete, I'll repeat some continuing problems with xl I posted at the end of October in the thread 'Problems with 'xl create winxp' (hvm) on Xen 4.1.2 (also affects GPLPV)':
3) Specifying vncviewer=1 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'.
Yes, I know about 'xl create --vncviewer' - it doesn't do anything. You still have to give a separate 'xl vncviewer <domanme>'.
4) The 'localtime=1' option in your config is ignored by xl. This works with
xm. Xl will not honor the rtc_timeoffset option either.
The answer given to the two above problems at the time was essentially that they had not been implemented. Have they been implemented in xen 4.2 yet? They are not mentioned in the xl.cfg documentation, which I assume is for 4.2:
http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
Now for what does work to get a stubdom up and running. I used the below config, with python commented out to keep xl happy. Note the spice options, and 'device_model_stubdomain_override = 1' don't actually do anything (the latter contrary to what someone else reported). I assume that they will become functional in xen 4.2. Also, while device_model_args does indeed add '-localtime' to the end of the qemu-dm args, it's still ineffective.
Two interesting observations: 1) 'xm create' is useless for creating stubdoms - I always get a page fault reported in qemu-dm-winxp.log (the log for the main domain, not the stubdom). In exploring this, I noticed that 'xm create' uses /usr/lib/xen/bin/stubdom.sh. You can add a 'set -x' to this file, and the trace will show up in qemu-dm-winxp.log. 'xl create' does not use this program. You can move it completely away from /usr/lib/xen/bin, and the stubdom will still be created. The device_model option is just telling xl not to use the normal qemu-dm method.
And 2) If you have GPLPV installed in your domain, it completely takes over. Booting with GPLPV enabled is no faster with stubdoms as without. Booting with /nogplpv is just as slow as if you booted without stubdoms. I suspect xenpci.sys is overriding what stubdoms is doing. The only part of the boot process that is faster is the initial grub screen. (This is an iscsi export from a dual-boot server.) After Windows starts to boot, it reverts back to gplpv (or /nogplpv) speeds. The same holds true for a linux hvm: a normal hvm domu with PvHvm drivers is no faster than a linux stubdom (w/no PvHvm). (I didn't try both at the same time.)
#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"
>
>
>
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'
# must comment out 'soundhw' below for stubdom
device_model = 'stubdom-dm'
device_model_stubdomain_override = 1
device_model_args=[ "-localtime" ]
#
keymap='en-us'
localtime=1
#rtc_timeoffset=' -14400'
rtc_timeoffset=' -18000'
pae=1
nx=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=16
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/sr0,hdc:cdrom,r' ]
#
#vif = [ 'mac=00:16:3e:23:1d:36, script=/etc/xen/scripts/vif-bridge, bridge=xenbr0, model=rtl8139' ]
vif = [ 'mac=00:16:3e:23:1d:36, type=ioemu, script=/etc/xen/scripts/vif-bridge, bridge=xenbr0, model=e1000' ]
#vif = [ 'mac=00:16:3e:23:1d:37, type=netfront, 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"
# 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=""
#spice
spice=1
spiceport=6000
spicehost='192.168.1.100'
spicedisable_ticketing = 0 # default is 0
spicepasswd = ''
| 
