Re: [Xen-devel] xenstore domain

[Juergen Gross <jgross@xxxxxxxx>]

On 10/12/15 22:13, Doug Goldstein wrote:
> On 12/9/15 1:34 AM, Juergen Gross wrote:
>> On 08/12/15 17:34, Andrew Cooper wrote:
>>> 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?
>>
>> What I need is the capability to do the XEN_DOMCTL_getdomaininfo
>> hypercall from the xenstore domain. Question is whether it's better
>> to tie this special capability to the flag or to name it "is_xenstore".
>>
>> Thinking more about it, especially regarding a possible enhancement
>> allowing Dom0 to reboot, I think the is_xenstore variant would be
>> better. This would allow to look whether a xenstore domain is already
>> running and connect to that rather than try to start a new one.
>>
>>
>> Juergen
> 
> How would either of these relate to /proc/xen/capabilities and/or
> /sys/hypervisor/properties/capabilities?

Not at all. Both files are dom0 products. And xenstore domain is not
a hypervisor capability, but just a configuration variant of the
system.

> A number of distros use the former to decide when to start up xenstore
> (in fact the in tree scripts do as well).

This is subject to dom0 configuration. In case it is configured to use
a xenstore domain it has to check whether this domain is already
running. The decision to start a new domain is depending on the result
of this test.


Juergen

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