[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Proposal: deprecate "vncviewer" option in xl domain config file
On Tue, 2014-04-22 at 16:19 +0100, Wei Liu wrote: > Hi all > > When I'm working on (de-)serialization of domain configurations I found > "vncviewer". I now propose to deprecate it. > > What it does is that if you have it set in your domain's config file and > do "xl create cfg", xl will automatically spawn a vncviewer for you. > This option actually controls the creation process of a domain but has > nothing to do with domain configuration at all. > > This option is buggy because it's also saved as part of domain state > when you do save / restore. Where is it saved? > Consider user migrates a domain to a remote > host, xl will try to auto-spawn vncviewer on the new host. This behavior > doesn't make sense at all. > > Further more it becomes an obstacle for the work to (de-)serialization > domain configurations. If we want to preserve this option we then need > to create abstraction for a config file in xl or libxl. This either > introduces lots of work without much benefit (if we add out-of-band > infomation in xl) or pollute libxl public interface. > > I propose to deprecate this option. > > What I will do is: > 1. config file still supports this option but it will prints out a > warning about its deprecation. > 2. this option is not saved as domain state when doing save / restore, > so when you restore a domain xl will not auto-spawn vncviewer. > > This may create a minor regression, but it's in no way critical. In > any case the right way to auto-spawn vncviewer is to use "-V" in "xl > create". And existing user of this config file option can also use "-V" > to work around this regression. > > Comments? 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. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |