[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC V2 10/10] xl: introduce "xl-json" format
On Tue, 2014-04-22 at 11:25 +0100, Wei Liu wrote: > On Tue, Apr 22, 2014 at 11:15:10AM +0100, Ian Campbell wrote: > > On Sat, 2014-04-19 at 09:35 +0100, Wei Liu wrote: > > > On Thu, Apr 17, 2014 at 12:13:11PM +0100, Wei Liu wrote: > > > > Originally xl verbatimly copies the domain config file in its user data > > > > store. This patch adds the functionality to transform text domain config > > > > file to JSON object and save that object in user data store. > > > > > > > > What this patch does: > > > > 1. add a mandatory flag to save protocol to indicate whether the saved > > > > config is a JSON object > > > > 2. register a new private data type "xl-json" in libxl.h > > > > 3. modify xl to save / load "xl-json" file where necessary > > > > > > > > After this change xl supports both "xl" format and "xl-json" format. > > > > The user-supplied config file is still restricted to normal text config > > > > file format ("xl"), as xl has more sanity checks when parsing text > > > > config file. "xl-json" format is only used internally. The saved config > > > > file is always in "xl-json" format. > > > > > > > > Tests done so far (xl.{new,old} denotes xl with{,out} "xl_json" > > > > support): > > > > 1. xl.new create then hexdump saved file: domain config saved in JSON > > > > format > > > > 2. xl.new create then xl.old restore: failed on mandatory flag check > > > > 3. xl.new create then xl.new restore: succeeded > > > > 4. xl.old create then xl.new restore: succeeded > > > > 5. xl.new create then local migrate, receiving end xl.new: succeeded > > > > 6. xl.old create then local migrate, receiving end xl.new: succeeded > > > > > > > > The only drawback is that when restoring a domain, xl cannot > > > > automatically spawn a vncviewer anymore. That's because that option is > > > > part of domain_create info not a domain configuration thus it's not > > > > saved in the JSON config. > > > > > > > > > > On a second thought I might as well create abstraction of a config file > > > in IDL. This might be more flexible in the long run. Then the burden > > > will be whenever an option that doesn't belong to domain_config is > > > added, IDL will also need to be taken care of. > > > > Is the issue here that the vnc autospawning is controlled via the xl > > command line (-A) rather than something in the configuration file? Or is > > there a config file way to do this too? > > > > It can be controlled by both. There's a "vncviewer" option in config > file but command line option will override that if set. > > If you look at parse_config_data you will see "vncviewer" is parsed and > assign to domain_create_info which is only used for domain creation. Oops, for some reason I searched for \"vnc (with the slash) when escaping wasn't needed or correct so I missed it. > > If it's because it is on the command line then we should be propagating > > that to the xl migrate-restore perhaps. > > > > auto-spawning a vncviewer on remote host? How is it useful for a user? > I don't have any prejudgement here so what I actually propose is just > providing a libxl abstraction of domain config file. What would consume this abstraction? Why does it have to be part of libxl? > +libxl_domain_config_file = Struct("domain_config_file", [ > + ("vncviewer", bool), > + ("domain_config", libxl_domain_config) > + ]) > > > We could also have xl transmit some state of its own outside of the > > domain configuration, either by using the IDL to do it in JSON or some > > other mechanism. > > > > I'm not sure about adding things to the libxl interface which libxl > > itself doesn't deal with just as a way to conveniently carry the > > information around. > > > > Libxl does use that. It needs those bits to rebuild domain. libxl can autospawn a vncviewer? I thought that was an xl feature. If it is actually a libxl feature then fine, but I think it makes most sense as an xl feature. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |