[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] CS 13088:057f7c4dbed1 partially breaks xm save



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.