Re: [PATCH] Initialization of new domU config optionsvia XenAPI

[Jim Fehlig <jfehlig@novell.com>]

Keir Fraser wrote:
> 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

>  -- Keir
>
> On 13/3/08 20:58, "Jim Fehlig" <jfehlig@novell.com> wrote:
>
>   
>> 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 <jfehlig@novell.com>
>>
>> diff -r f33328217eee tools/python/xen/xend/XendConfig.py
>> --- a/tools/python/xen/xend/XendConfig.py Mon Mar 10 22:51:57 2008 +0000
>> +++ b/tools/python/xen/xend/XendConfig.py Thu Mar 13 14:55:16 2008 -0600
>> @@ -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
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>     
>
>
>