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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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