Re: [Xen-devel] Proposal: deprecate "vncviewer" option in xl domain config file

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-04-22 at 17:32 +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: Proposal: deprecate "vncviewer" option in xl domain 
> config file"):
> > On Tue, Apr 22, 2014 at 04:50:56PM +0100, Ian Campbell wrote:
> > > Where is it saved?
> > 
> > The domain config file is saved, then used when restoring. Restoring
> > process involves re-parsing that config file.
> 
> Ie the domain configuration file provided to xl create is saved in the
> libxl userdata.  During xl save, that domain configuration file is
> recorded in the save image.  During xl restore, it is extracted from
> the save image and reparsed.  If the original configuration file
> contained "vncviewer=1", this will result in xl restore running the
> vncviewer, regardless of xl restore's command line arguments.

Right, but Wei is removing this reparsing of the vncviewer.

> > > Rather than throwing the baby out with the bathwater can't we just say
> > > that this option is only obeyed for the initial domain creation and not
> > > for any subsequent migration or restore? What would avoid the need to
> > > propagate it along with the save/migrate image.
> > 
> > I think this is just wording issue. My "xl-json" format patch does this
> > already.  I'm OK with any approach as long as I don't need to propogate
> > it. :-P
> 
> Precisely.

Yes, I think it was unclear whether the intention was only to deprecate
the option on restore/migration or entirely. The former is unequivocally
fine IMHO.

> Although, I would go further and say that this kind of thing shouldn't
> be in the domain config file.  The same config file should be able to
> start a domain both with and without automatically running vncviewer.
> 
> After all we don't have an xl domain config file option for
> automatically running xenconsole - we rely, only, on the -c option for
> that.

I mostly agree, but this is the sort of thing which xend users might
think was a functional regression, not that this should be a blocker if
we really think this behaviour is intolerably bad/strange.

Ian.


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