Re: [Xen-devel] making xenstore domain easy configurable

[Juergen Gross <jgross@xxxxxxxx>]

On 27/06/16 22: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.

Generally I like the idea.

Just did a basic test and it seems just to work:

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index d1e01ba..8d806cb 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -288,10 +288,12 @@ struct xs_handle *xs_open(unsigned long flags)
 {
        struct xs_handle *xsh = NULL;

+#if 0
        if (flags & XS_OPEN_READONLY)
                xsh = get_handle(xs_daemon_socket_ro());
        else
                xsh = get_handle(xs_daemon_socket());
+#endif

        if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
                xsh = get_handle(xs_domain_dev());

Doing "strace xenstore-ls" verified the tool is now using the kernel
interface in dom0 with xenstored running. Using "time xenstore-ls"
showed no performance drop (the numbers are rather low; if any
difference is really measurable the socket variant seems to be a
little bit slower).

My conclusion: I'm going this route (thanks, Doug!), patches will
follow soon.


Juergen

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