Initialization of new domU config options via XenAPI
PATCH 1/1 Initialization of new domU config options via XenAPI
Many of the new domU config options related to hvm guests (e.g. hpet, rtc_timeoffset, etc.) are not initialized with default values via XenAPI, which prevents starting an hvm domU created through XenAPI. This patch ensures the new options are set with appropriate default values in XendConfig platform sanity check.
tools/python/xen/xend/XendConfig.py +6 -0
@@ -405,6 +405,12 @@ class XendConfig(dict): self['platform']['device_model'] = xen.util.auxbin.pathTo("qemu-dm") if self.is_hvm(): + if 'timer_mode' not in self['platform']: + self['platform']['timer_mode'] = 0 + if 'rtc_timeoffset' not in self['platform']: + self['platform']['rtc_timeoffset'] = 0 + if 'hpet' not in self['platform']: + self['platform']['hpet'] = 0 if 'loader' not in self['platform']: # Old configs may have hvmloader set as PV_kernel param if self.has_key('PV_kernel') and re.search('hvmloader', self['PV_kernel']):
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
It's quite valid not to have 'hpet' explicitly set; also I think 'timer_mode'. What problems do you see, and do they really happen with all three config items?
-- Keir
Quoted 30 lines · Jim Fehlig
Many of the new domU config options related to hvm guests (e.g. hpet,
rtc_timeoffset, etc.) are not initialized with default values via XenAPI, which prevents starting an hvm domU created through XenAPI. This patch ensures the new options are set with appropriate default values in XendConfig platform sanity check.Signed-off-by Jim Fehlig <[email protected]>diff -r
f33328217eeetools/python/xen/xend/XendConfig.pytools/python/xen/xend/XendConfig.py Thu Mar 13 14:55:16 2008 -0600 renamed from tools/python/xen/xend/XendConfig.py Mon Mar 10 22:51:57 2008 +0000 +6
-0@@ -405,6 +405,12 @@ class XendConfig(dict): self['platform']['device_model'] = xen.util.auxbin.pathTo("qemu-dm") if self.is_hvm(): + if 'timer_mode' not in self['platform']: + self['platform']['timer_mode'] = 0 + if 'rtc_timeoffset' not in self['platform']: + self['platform']['rtc_timeoffset'] = 0 + if 'hpet' not in self['platform']: + self['platform']['hpet'] = 0 if 'loader' not in self['platform']: # Old configs may have hvmloader set as PV_kernel paramif
self.has_key('PV_kernel')and re.search('hvmloader',
self['PV_kernel']):
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Re: [PATCH] Initialization of new domU config optionsvia XenAPI
Quoted 4 lines · Keir Fraser
It's quite valid not to have 'hpet' explicitly set; also I think '
timer_mode'. What problems do you see, and do they really happen with all three config items?
Without timer_mode set:
jfehlig4:~ # xm start sles10sp2b4-fv-32
Error: long() argument must be a string or a number
Usage: xm start <DomainName>
and in xend.log
[2008-03-14 11:16:23 17758] ERROR (xmlrpclib2:178) Internal error handling xend.domain.start
Traceback (most recent call last):
File "/usr/lib64/python2.4/site-packages/xen/util/xmlrpclib2.py", line
131, in _marshaled_dispatch
response = self._dispatch(method, params)
File "/usr/lib64/python2.4/SimpleXMLRPCServer.py", line 406, in _dispatch
return func(*params)
File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomain.py", line
1030, in domain_start
dominfo.start(is_managed = True)
File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 419, in start
XendTask.log_progress(0, 30, self._constructDomain)
File "/usr/lib64/python2.4/site-packages/xen/xend/XendTask.py", line
209, in log_progress
retval = func(*args, **kwds)
File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 1711, in _constructDomain
long(self.info["platform"].get("timer_mode")))TypeError: long() argument must be a string or a number
Without hpet set I see time jumping all over the place in (at least) 32-bit HVM linux domU. E.g. a simple script such as "while true; do date; sleep 1; done" running in the domU produces
Sat Mar 15 00:16:13 MDT 2008
Sat Mar 15 02:58:28 MDT 2008
Sat Mar 15 02:58:29 MDT 2008
Sat Mar 15 02:59:20 MDT 2008
Sat Mar 15 02:59:21 MDT 2008
Sat Mar 15 02:59:22 MDT 2008
Sat Mar 15 03:01:06 MDT 2008
Sat Mar 15 03:01:07 MDT 2008
Sat Mar 15 03:01:59 MDT 2008
Sat Mar 15 03:02:51 MDT 2008
Sat Mar 15 03:03:43 MDT 2008
Sat Mar 15 03:03:44 MDT 2008
Sat Mar 15 03:04:35 MDT 2008
Sat Mar 15 03:05:27 MDT 2008
And finally, without rtc_timeoffset set before staring domU
jfehlig4:~ # xm li -l sles-fv-32 | grep rtc_timeoffset jfehlig4:~ #
and after starting
jfehlig4:~ # xm li -l sles-fv-32 | grep rtc_timeoffset
(rtc_timeoffset -25200)
jfehlig4:~ #
which is obviously not what I wanted given localtime=0.
Cheers,
Jim
Quoted 39 lines
-- Keir
Quoted 31 lines · Jim Fehlig
Many of the new domU config options related to hvm guests (e.g. hpet,
rtc_timeoffset, etc.) are not initialized with default values via XenAPI, which prevents starting an hvm domU created through XenAPI. This patch ensures the new options are set with appropriate default values in XendConfig platform sanity check.Signed-off-by Jim Fehlig <[email protected]>diff -r
f33328217eeetools/python/xen/xend/XendConfig.pytools/python/xen/xend/XendConfig.py Thu Mar 13 14:55:16 2008 -0600 renamed from tools/python/xen/xend/XendConfig.py Mon Mar 10 22:51:57 2008 +0000 +6
-0@@ -405,6 +405,12 @@ class XendConfig(dict): self['platform']['device_model'] = xen.util.auxbin.pathTo("qemu-dm") if self.is_hvm(): + if 'timer_mode' not in self['platform']: + self['platform']['timer_mode'] = 0 + if 'rtc_timeoffset' not in self['platform']: + self['platform']['rtc_timeoffset'] = 0 + if 'hpet' not in self['platform']: + self['platform']['hpet'] = 0 if 'loader' not in self['platform']: # Old configs may have hvmloader set as PV_kernel paramif
self.has_key('PV_kernel')and re.search('hvmloader',
self['PV_kernel']):
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel