Re: making xenstore domain easy configurable

[David Vrabel <david.vrabel@citrix.com>]

On 27/06/16 21:59, Doug Goldstein wrote:
> On 6/27/16 7:59 AM, Andrew Cooper wrote:
>> On 27/06/16 13:43, Juergen Gross wrote:
>>> I'm just writing some patches to make it easy to switch between
>>> xenstore daemon and xenstore domain. My plan is to achieve this
>>> by a global configuration file containing configuration options
>>> for the host (e.g. /etc/xen/xen.conf).
>>>
>>> With the current systemd support this is not easy. There are
>>> systemd socket definitions to let systemd create the sockets for
>>> xenstored. As the sockets are not to be created in case xenstore
>>> is running in a xenstore domain things are becoming complicated.
>>>
>>> Today we have the following xenstore related systemd items:
>>>
>>> - xenstored_ro.socket and xenstored.socket
>>> - xenstored.service depending on the sockets
>>> - other services depending on xenstored.service
>>>
>>> A xenstore domain would need:
>>>
>>> - xenstore-domain.service
>>> - other services depending on xenstore-domain.service
>>>
>>> Being able to switch between both schemes just via a config file
>>> seems to be not easy, at least I don't know of any way to do the
>>> socket creation only in case they are required without breaking
>>> the dependency chain.
>>>
>>> So I'd suggest to remove xenstored_ro.socket and xenstored.socket
>>> and let xenstored create the sockets (as it is doing without
>>> systemd). I'm not aware of any disadvantage, as xenstored isn't
>>> restartable and thus can't take advantage of the permanent sockets
>>> offered by systemd.
>>>
>>> This would mean I could rip out the systemd specific stuff from
>>> xenstored and oxenstored. I could create a single xenstore.service
>>> script evaluating the config file and starting the correct xenstore
>>> (xenstored or xenstore domain). The other services would then depend
>>> on xenstore.service. This would remove the need to specify the
>>> type of xenstore daemon/domain (ocaml based or C based) in the systemd
>>> file, too.
>>>
>>> Is there a better way to achieve what I want? Any other opinions?
>>
>> This isn't the only advantage offered by socket activation.
>>
>> As currently configured, every service which depends on xenstored.socket
>> can be started in parallel (as systemd creates the sockets ahead of
>> time), with the dependent services blocking a little on the socket while
>> xenstored starts up sufficiently to service the requests.
>>
>> In the case that xenstored is running in the local domain, socket
>> activation is a useful function to have.
>>
>> OTOH, having anything explicitly depend on xenstored.socket is broken in
>> a model where xenstored might be running in a separate domain.  I don't
>> suppose systemd has any way of specifying "conditionally might have a
>> socket"?
>>
>> ~Andrew
> 
> How about we take this the other way? Let's go away from using the
> socket and always go through kernel interface. I understand that its
> faster to use sockets than using the interface but does this performance
> difference really affect an actual running system. If we manage to steer
> people towards a stubdom xenstore they won't have the option of using
> the sockets anyway. Just thinking that supporting two different
> interfaces always seems clumsy.

xs_restrict() which QEMU will be making use of requires the unix domain
socket.

So I don't think we want to go down this route unless xs_restrict() can
be made to work via the kernel interface as well.

David

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