While refreshing my checkpoint patches, I've stumbled on a buglet
introduced by changeset 13088. It seems from this point on, a domain
created with a config file that includes a cpus entry (eg cpus = "1")
will cause xm save to produce a guest record that xm restore can't
parse. Here's the traceback:
Traceback (most recent call last):
File
"/home/brendan/dev/xen/xen-ss.hg/dist/install/usr/lib/python/xen/xend/XendDomain.py",
line 996, in domain_restore_fd
File
"/home/brendan/dev/xen/xen-ss.hg/dist/install/usr/lib/python/xen/xend/XendCheckpoint.py",
line 142, in restore
File
"/home/brendan/dev/xen/xen-ss.hg/dist/install/usr/lib/python/xen/xend/XendDomain.py",
line 474, in restore_
File
"/home/brendan/dev/xen/xen-ss.hg/dist/install/usr/lib/python/xen/xend/XendDomainInfo.py",
line 204, in restore
File
"/home/brendan/dev/xen/xen-ss.hg/dist/install/usr/lib/python/xen/xend/XendConfig.py",
line 296, in __init__
File
"/home/brendan/dev/xen/xen-ss.hg/dist/install/usr/lib/python/xen/xend/XendConfig.py",
line 588, in _sxp_to_xapi
File
"/home/brendan/dev/xen/xen-ss.hg/dist/install/usr/lib/python/xen/xend/XendConfig.py",
line 554, in _parse_sxp
AttributeError: 'list' object has no attribute 'split'
And here's a bit of the bogus(?) guest record:
(domain (domid 1) (on_crash destroy) (memory 128) (uuid
355826d4-dca6-952c-53ed-564fd726a379) (name ubuntu) (maxmem 128) (cpus (1))
(on_reboot restart) (on_poweroff destroy) (localtime 0) (vcpus 1)
(shadow_memory 0) (vcpu_avail 1) (cpu_weight 256) (cpu_cap 0) (features )
(on_xend_start ignore) (on_xend_stop ignore) (start_time 1168323062.52)
(cpu_time 14.227213722) (online_vcpus 1) (cpus (1)) (cpus (1)) ...
Is anyone else seeing this?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|