Re: [Xen-devel] xenstore domain

[Doug Goldstein <cardoe@xxxxxxxxxx>]

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?

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

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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