Re: [Xen-devel] [PATCH RFC V2 10/10] xl: introduce "xl-json" format

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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.

> 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.

+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.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel