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"
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''
# 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 = ''''
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
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"
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''
# 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 = ''''
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On Thu, 2012-02-16 at 10:11 +0000, jim burns wrote: [...]> 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:[..] I tried this with win7 on xen-unstable and it worked ok. This may be a bug specific to 4.1. [...]> xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8"> and only got a syntax error on the ''-d''.I don''t think this approach is advised but FWIW the error here is probably lack of quoting of the " against the shell. You would have needed ... extra=\" -d 8\"> So my question is: is this a bug, and is it fixed in xen 4.2?The failure to restart the stub DM when rebooting a VM is a bug, AFAICT it is fixed in unstable and therefore will be fixed in 4.2. I''ve not been able to spot a specific changeset with the fix, but there was quite a lot to wade through.> 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.Stop working for a day and then magically starts working? Or stops working for a day until the next update?> 3) Specifying vncviewer=1 will automatically start a vnc viewer for > you[...]> 4) The ''localtime=1'' option in your config is ignored by xl. This > works with[...]> 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?Not as far as I can tell with grep. Patches would be greatly appreciated, these should be relatively simple issues for a newcomer to tackle with only basic C required I think, I''d be glad to advise etc. I''ll add these as "nice to have" in the 4.2 TODO thread.> They are not mentioned in the xl.cfg documentation, which I assume is > for 4.2:Correct. [...]> 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).Yes, I think these are the 4.2 names, In 4.1 you likely need device_model = "stubdom-dm"> I assume that they will become functional in xen 4.2.Yes.> Also, while device_model_args does indeed add ''-localtime'' to the end > of the qemu-dm args, it''s still ineffective.I''m not 100% sure of this but I don''t think xm''s "localtime" corresponds to solely passing "-localtime" to the DM (although it may also do that also). I think it needs to turn into a hypercall to tell the hypervisor about the guests time offset, e.g. a call to xc_domain_set_time_offset. The rtc_timeoffset option relates to this call as well. In a Xen system the RTC is emulated by the hypervisor not by qemu (it used to be done by qemu many moons ago, which might explain the vestigial passing of -localtime to qemu).> 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.If you are using PV devices then you won''t be hitting the emulated devices (which is what is in the stubdom) all that much after the very early boot stages IOW after anything which uses BIOS int13 hook e.g. the bootloader. If you aren''t hitting the emulated devices then putting them in stubdom vs dom0 won''t make much odds to the performance. Ian.
On Thu, 2012-02-16 at 10:11 +0000, jim burns wrote: [...]> 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:[..] I tried this with win7 on xen-unstable and it worked ok. This may be a bug specific to 4.1. [...]> xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8"> and only got a syntax error on the ''-d''.I don''t think this approach is advised but FWIW the error here is probably lack of quoting of the " against the shell. You would have needed ... extra=\" -d 8\"> So my question is: is this a bug, and is it fixed in xen 4.2?The failure to restart the stub DM when rebooting a VM is a bug, AFAICT it is fixed in unstable and therefore will be fixed in 4.2. I''ve not been able to spot a specific changeset with the fix, but there was quite a lot to wade through.> 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.Stop working for a day and then magically starts working? Or stops working for a day until the next update?> 3) Specifying vncviewer=1 will automatically start a vnc viewer for > you[...]> 4) The ''localtime=1'' option in your config is ignored by xl. This > works with[...]> 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?Not as far as I can tell with grep. Patches would be greatly appreciated, these should be relatively simple issues for a newcomer to tackle with only basic C required I think, I''d be glad to advise etc. I''ll add these as "nice to have" in the 4.2 TODO thread.> They are not mentioned in the xl.cfg documentation, which I assume is > for 4.2:Correct. [...]> 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).Yes, I think these are the 4.2 names, In 4.1 you likely need device_model = "stubdom-dm"> I assume that they will become functional in xen 4.2.Yes.> Also, while device_model_args does indeed add ''-localtime'' to the end > of the qemu-dm args, it''s still ineffective.I''m not 100% sure of this but I don''t think xm''s "localtime" corresponds to solely passing "-localtime" to the DM (although it may also do that also). I think it needs to turn into a hypercall to tell the hypervisor about the guests time offset, e.g. a call to xc_domain_set_time_offset. The rtc_timeoffset option relates to this call as well. In a Xen system the RTC is emulated by the hypervisor not by qemu (it used to be done by qemu many moons ago, which might explain the vestigial passing of -localtime to qemu).> 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.If you are using PV devices then you won''t be hitting the emulated devices (which is what is in the stubdom) all that much after the very early boot stages IOW after anything which uses BIOS int13 hook e.g. the bootloader. If you aren''t hitting the emulated devices then putting them in stubdom vs dom0 won''t make much odds to the performance. Ian.
On Fri February 17 2012, 10:22:12 AM, Ian Campbell wrote:> On Thu, 2012-02-16 at 10:11 +0000, jim burns wrote: > [...] > > > 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: > [..] > > I tried this with win7 on xen-unstable and it worked ok. This may be a > bug specific to 4.1.Good to know! Thank you very much for taking the time to look at this.> [...] > > > xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8" > > > > and only got a syntax error on the ''-d''. > > I don''t think this approach is advised but FWIW the error here is > probably lack of quoting of the " against the shell. You would have > needed > ... extra=\" -d 8\"Ouch! I was trying to quote the ''-'' in -d!> > So my question is: is this a bug, and is it fixed in xen 4.2? > > The failure to restart the stub DM when rebooting a VM is a bug, AFAICT > it is fixed in unstable and therefore will be fixed in 4.2. > > I''ve not been able to spot a specific changeset with the fix, but there > was quite a lot to wade through. > > > 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. > > Stop working for a day and then magically starts working? Or stops > working for a day until the next update?As it turns out, both, the two times it happened to me. Stubdoms stop working until the next yum update, but nothing installed the next day has any relationship to xen or a kernel. Whether or not it would have worked 1/2 hour before the yum update is not something I have had an opportunity to explore yet. Of course, a yum update is frequently accompanied by a systemd restart, which could have an effect. Whenever I get a rawhide xen or kernel update, I usually reboot to test the update for regressions/bugs, then reboot back to the highest version kernel I have w/o debug options turned off (before the next yum update). Thus, a full reboot, twice, doesn''t fix the problem. So I would think that a simple systemd restart wouldn''t, either. That''s why the next thing I intend to look at would be whether anything got damaged/not regenerated in /var/lib/xen*. Another possibility is that xend is still running. I usually take care not to mix xm and xl commands in one boot session. If I do mix them, I usually stop any domus, and do an ''xm mem-set 0 ...'' back to the boot value in my system, and then use only one of the xm / xl commands thereafter. (It is really disconcerting to see xm list, xl list report differing dom0 memory amounts!) Anyway, stopping xend and trying stubdoms again is something else I will try.> > 3) Specifying vncviewer=1 will automatically start a vnc viewer for > > you > > [...] > > > 4) The ''localtime=1'' option in your config is ignored by xl. This > > works with > > [...] > > > 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? > > Not as far as I can tell with grep. Patches would be greatly > appreciated, these should be relatively simple issues for a newcomer to > tackle with only basic C required I think, I''d be glad to advise etc. > > I''ll add these as "nice to have" in the 4.2 TODO thread.That is greatly appreciated. While I was a programmer awhile back, I have not read the xen code, and the learning curve there, and in learning how to write *acceptable* patches is more than my time constraints currently allow. I confine my time to administrative duties, and looking for bugs / regressions to report, and helping the occasional user on Xen-users with what I *have* learned. [...]> > Also, while device_model_args does indeed add ''-localtime'' to the end > > > > of the qemu-dm args, it''s still ineffective. > > I''m not 100% sure of this but I don''t think xm''s "localtime" corresponds > to solely passing "-localtime" to the DM (although it may also do that > also). > > I think it needs to turn into a hypercall to tell the hypervisor about > the guests time offset, e.g. a call to xc_domain_set_time_offset. The > rtc_timeoffset option relates to this call as well.That makes sense. Thanx.> In a Xen system the RTC is emulated by the hypervisor not by qemu (it > used to be done by qemu many moons ago, which might explain the > vestigial passing of -localtime to qemu).And I''ve been with xen since the 3.0 days, so features start merging in my head! Thanx for the clarity!.> > 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. > > If you are using PV devices then you won''t be hitting the emulated > devices (which is what is in the stubdom) all that much after the very > early boot stages IOW after anything which uses BIOS int13 hook e.g. the > bootloader. If you aren''t hitting the emulated devices then putting them > in stubdom vs dom0 won''t make much odds to the performance. > > Ian.Makes sense. The main thing that I was disappointed in was that even booting with /nogplpv didn''t result in a speed increase. xenpci.sys seems to take over completely, even in that case. Thanx again for your time and interest. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri February 17 2012, 10:22:12 AM, Ian Campbell wrote:> On Thu, 2012-02-16 at 10:11 +0000, jim burns wrote: > [...] > > > 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: > [..] > > I tried this with win7 on xen-unstable and it worked ok. This may be a > bug specific to 4.1.Good to know! Thank you very much for taking the time to look at this.> [...] > > > xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8" > > > > and only got a syntax error on the ''-d''. > > I don''t think this approach is advised but FWIW the error here is > probably lack of quoting of the " against the shell. You would have > needed > ... extra=\" -d 8\"Ouch! I was trying to quote the ''-'' in -d!> > So my question is: is this a bug, and is it fixed in xen 4.2? > > The failure to restart the stub DM when rebooting a VM is a bug, AFAICT > it is fixed in unstable and therefore will be fixed in 4.2. > > I''ve not been able to spot a specific changeset with the fix, but there > was quite a lot to wade through. > > > 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. > > Stop working for a day and then magically starts working? Or stops > working for a day until the next update?As it turns out, both, the two times it happened to me. Stubdoms stop working until the next yum update, but nothing installed the next day has any relationship to xen or a kernel. Whether or not it would have worked 1/2 hour before the yum update is not something I have had an opportunity to explore yet. Of course, a yum update is frequently accompanied by a systemd restart, which could have an effect. Whenever I get a rawhide xen or kernel update, I usually reboot to test the update for regressions/bugs, then reboot back to the highest version kernel I have w/o debug options turned off (before the next yum update). Thus, a full reboot, twice, doesn''t fix the problem. So I would think that a simple systemd restart wouldn''t, either. That''s why the next thing I intend to look at would be whether anything got damaged/not regenerated in /var/lib/xen*. Another possibility is that xend is still running. I usually take care not to mix xm and xl commands in one boot session. If I do mix them, I usually stop any domus, and do an ''xm mem-set 0 ...'' back to the boot value in my system, and then use only one of the xm / xl commands thereafter. (It is really disconcerting to see xm list, xl list report differing dom0 memory amounts!) Anyway, stopping xend and trying stubdoms again is something else I will try.> > 3) Specifying vncviewer=1 will automatically start a vnc viewer for > > you > > [...] > > > 4) The ''localtime=1'' option in your config is ignored by xl. This > > works with > > [...] > > > 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? > > Not as far as I can tell with grep. Patches would be greatly > appreciated, these should be relatively simple issues for a newcomer to > tackle with only basic C required I think, I''d be glad to advise etc. > > I''ll add these as "nice to have" in the 4.2 TODO thread.That is greatly appreciated. While I was a programmer awhile back, I have not read the xen code, and the learning curve there, and in learning how to write *acceptable* patches is more than my time constraints currently allow. I confine my time to administrative duties, and looking for bugs / regressions to report, and helping the occasional user on Xen-users with what I *have* learned. [...]> > Also, while device_model_args does indeed add ''-localtime'' to the end > > > > of the qemu-dm args, it''s still ineffective. > > I''m not 100% sure of this but I don''t think xm''s "localtime" corresponds > to solely passing "-localtime" to the DM (although it may also do that > also). > > I think it needs to turn into a hypercall to tell the hypervisor about > the guests time offset, e.g. a call to xc_domain_set_time_offset. The > rtc_timeoffset option relates to this call as well.That makes sense. Thanx.> In a Xen system the RTC is emulated by the hypervisor not by qemu (it > used to be done by qemu many moons ago, which might explain the > vestigial passing of -localtime to qemu).And I''ve been with xen since the 3.0 days, so features start merging in my head! Thanx for the clarity!.> > 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. > > If you are using PV devices then you won''t be hitting the emulated > devices (which is what is in the stubdom) all that much after the very > early boot stages IOW after anything which uses BIOS int13 hook e.g. the > bootloader. If you aren''t hitting the emulated devices then putting them > in stubdom vs dom0 won''t make much odds to the performance. > > Ian.Makes sense. The main thing that I was disappointed in was that even booting with /nogplpv didn''t result in a speed increase. xenpci.sys seems to take over completely, even in that case. Thanx again for your time and interest. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri February 17 2012, 3:14:39 PM, jim burns wrote:> > 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. > > Stop working for a day and then magically starts working? Or stops > working for a day until the next update? As it turns out, both, the two times it happened to me. Stubdoms stop working until the next yum update, but nothing installed the next day has any relationship to xen or a kernel. Whether or not it would have worked 1/2 hour before the yum update is not something I have had an opportunity to explore yet. Of course, a yum update is frequently accompanied by a systemd restart, which could have an effect. Well, at least I got this one figured out. It wasn''t the next day''s yum update that fixes things - it was another cron daily job: prelink. I just got a xen update (fedora rawhide), I stopped my stubdom, tried to start it again, and it failed. Then I ran the prelink job again (it normally executes before yum, which I had changed) - and lo and behold, my stubdom started! Xen commands are the only commands that I haven''t been able to execute w/o prelink-ing, and only this one function, so I didn''t immediately suspect that running yum after prelink would be a problem. Live and learn! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Fri February 17 2012, 3:14:39 PM, jim burns wrote:> > 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. > > Stop working for a day and then magically starts working? Or stops > working for a day until the next update? As it turns out, both, the two times it happened to me. Stubdoms stop working until the next yum update, but nothing installed the next day has any relationship to xen or a kernel. Whether or not it would have worked 1/2 hour before the yum update is not something I have had an opportunity to explore yet. Of course, a yum update is frequently accompanied by a systemd restart, which could have an effect. Well, at least I got this one figured out. It wasn''t the next day''s yum update that fixes things - it was another cron daily job: prelink. I just got a xen update (fedora rawhide), I stopped my stubdom, tried to start it again, and it failed. Then I ran the prelink job again (it normally executes before yum, which I had changed) - and lo and behold, my stubdom started! Xen commands are the only commands that I haven''t been able to execute w/o prelink-ing, and only this one function, so I didn''t immediately suspect that running yum after prelink would be a problem. Live and learn! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, 2012-03-08 at 18:07 -0500, jim burns wrote:> Well, at least I got this one figured out. It wasn''t the next day''s > yum update that fixes things - it was another cron daily job: prelink. > I just got a xen update (fedora rawhide), I stopped my stubdom, tried > to start it again, and it failed. Then I ran the prelink job again (it > normally executes before yum, which I had changed) - and lo and > behold, my stubdom started!> Xen commands are the only commands that I haven''t been able to execute > w/o prelink-ing, and only this one function, so I didn''t immediately > suspect that running yum after prelink would be a problem. Live and > learn!Wow, first time I''ve heard of prelinking _fixing_ something! Ian.
On Thu, 2012-03-08 at 18:07 -0500, jim burns wrote:> Well, at least I got this one figured out. It wasn''t the next day''s > yum update that fixes things - it was another cron daily job: prelink. > I just got a xen update (fedora rawhide), I stopped my stubdom, tried > to start it again, and it failed. Then I ran the prelink job again (it > normally executes before yum, which I had changed) - and lo and > behold, my stubdom started!> Xen commands are the only commands that I haven''t been able to execute > w/o prelink-ing, and only this one function, so I didn''t immediately > suspect that running yum after prelink would be a problem. Live and > learn!Wow, first time I''ve heard of prelinking _fixing_ something! Ian.
On Thu March 8 2012, 4:30:11 PM, Ian Campbell wrote:> On Thu, 2012-03-08 at 18:07 -0500, jim burns wrote: > > Well, at least I got this one figured out. It wasn''t the next day''s > > yum update that fixes things - it was another cron daily job: prelink. > > I just got a xen update (fedora rawhide), I stopped my stubdom, tried > > to start it again, and it failed. Then I ran the prelink job again (it > > normally executes before yum, which I had changed) - and lo and > > behold, my stubdom started! > > > > Xen commands are the only commands that I haven''t been able to execute > > w/o prelink-ing, and only this one function, so I didn''t immediately > > suspect that running yum after prelink would be a problem. Live and > > learn! > > Wow, first time I''ve heard of prelinking _fixing_ something! > > Ian.He he. Yeah, I had a problem with Avira Antivir, until I realized that it''s directory had to be excluded from prelink. Each (app) to their own! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu March 8 2012, 4:30:11 PM, Ian Campbell wrote:> On Thu, 2012-03-08 at 18:07 -0500, jim burns wrote: > > Well, at least I got this one figured out. It wasn''t the next day''s > > yum update that fixes things - it was another cron daily job: prelink. > > I just got a xen update (fedora rawhide), I stopped my stubdom, tried > > to start it again, and it failed. Then I ran the prelink job again (it > > normally executes before yum, which I had changed) - and lo and > > behold, my stubdom started! > > > > Xen commands are the only commands that I haven''t been able to execute > > w/o prelink-ing, and only this one function, so I didn''t immediately > > suspect that running yum after prelink would be a problem. Live and > > learn! > > Wow, first time I''ve heard of prelinking _fixing_ something! > > Ian.He he. Yeah, I had a problem with Avira Antivir, until I realized that it''s directory had to be excluded from prelink. Each (app) to their own! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users