From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: xenstore domain Date: Tue, 8 Dec 2015 16:34:13 +0000 Message-ID: <56670685.4060407@citrix.com> References: <5666ECBE.6090102@suse.com> <5666F16D.7040804@citrix.com> <5666FF19.5020200@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5666FF19.5020200@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Juergen Gross , "xen-devel@lists.xen.org" , David Scott List-Id: xen-devel@lists.xenproject.org On 08/12/15 16:02, Juergen Gross wrote: > On 08/12/15 16:04, Andrew Cooper wrote: >> On 08/12/15 14:44, Juergen Gross wrote: >>> I'm just playing a little bit with xenstore in an own domain. >>> >>> I've come across some questions I'd like to have some answers to before >>> presenting official patches to make this an easy configurable option: >>> >>> a) As this would need a boot time configuration item I'd like to add >>> e.g. /etc/xen/server.conf where such global configuration options >>> could be set via directives. Is this generally okay? If yes, which >>> format? Easiest way would be entries like >>> VAR=value >>> which can be either sourced in from shell scripts or can easily be >>> parsed in all programming languages. What are the preferences here? >> Any configuration like this going to be toolstack-specific. I would >> recommend against using a name as generic as that. >> >> /etc/xl.conf already exists, which IMO would be the natural place for >> this to live, but it isn't parseable by shell, because of vif notation. > OTOH that file wouldn't be just for xl. It would be consumed by e.g. > xencommons. Other configuration options I'd plan to add would be > driver domains dedicated to specific interface cards. It is still logically part of the "xl toolstack infrastructure", but I accept your point. The current xl.conf is all about how to create domains in general, rather than specifically "how I would like my system configured when starting up". > >> One option might be to alter xl.conf to be compatible with shell >> parsing. It wouldn't be complicated (even in upgrade situations), and >> would offer rather more flexibility. > Shell parsing could be even handled via a rather simple filter, I guess. > >>> b) Today init-xenstore-domain will require flask to be enabled. An >>> alternative would be to add a new domain creation flag to allow the >>> domains with that flag set calling xc_domain_getinfo(). Thoughts? >> Which flag? > A new domcr_flag. Indicating what, precisely? > >>> c) In order to be as flexible as possible I think the xenstore domain >>> should be allowed to auto-balloon according to it's needs. Is anyone >>> already working on ballooning support for mini-os? >> This is the C xenstore? Have you investigated whether Mirage-based >> stubdomains can balloon? > Aren't they based on mini-os, too? Heavily modified. For one, they have fixed suspend/resume. I don't know whether they have ballooning, and it isn't completely obvious from their repo. Dave: any ideas? ~Andrew