Re: [Xen-devel] xenstore domain

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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

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