Re: [Xen-devel] [PATCH] systemd: add support initial systemd service files

["Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxxxxx>]

On Wed, Mar 12, 2014 at 12:44 PM, M A Young <m.a.young@xxxxxxxxxxxx> wrote:
> Fedora has the following systemd files (in xen-4.3)
>
> proc-xen.mount - to mount /proc/xen

OK

> var-lib-xenstored.mount - to create a tmpfs mount at /var/lib/xenstored

/var/lib/xenstored is the default path but why is tmpfs used? Are we
supposed to shred the TBD upon reboot? I can see how using memory
would yield better results than a filesystem, and it seems my tbd gets
rid of anything other than dom0 data after reboot. Without starting
xenstored I get upon boot:

mcgrof@ergon ~ $ sudo tdbtool /var/lib/xenstored/tdb dump| grep "/local/"
/local/domain/0/device-model
/local/domain
/local/domain/0/memory/static-max
/local/domain/0/memory/target
/local/domain/0/name
/local/domain/0/device-model/0
/local/domain/0/domid
/local/domain/0/memory/freemem-slack
/local/domain/0/libxl
/local/domain/0/memory
/local/domain/0/libxl/disable_udev
/local/domain/0
/local/domain/0/device-model/0/state

Are there no gains in keeping that?

I will note that upon starting xenstored I then get:

mcgrof@ergon ~ $ sudo tdbtool /var/lib/xenstored/tdb dump| grep "/local/"
/local/domain/0/device-model
/local/domain
/local/domain/0/name
/local/domain/0/device-model/0
/local/domain/0/domid
/local/domain/0
/local/domain/0/device-model/0/state

I am not sure so I guess that the initial tdb is cleared then? I see
that the pld linux systemd scripts clear the file anyway, so maybe
there is no point to make it stateful across reboots.

What if we save / restore a guest state?

> xenstored.service - to start xenstored (if /proc/xen/capabilities exists)
> and to set /local/domain/0/name in xenstore
>
> oxenstored.service - the same as xenstored.service but to start oxenstored.
> It conflicts with xenstored.service which means it should get started
> instead of xenstored if both are installed

Neat!

> blktapctrl.service - to start blktapctrl though I don't think it has ever
> been useful in Fedora and I intend to drop it when I build a xen 4.4.0
> package.

OK so lets ignore that.

> xenconsoled.service - to start xenconsoled

OK

> xend.service - to start xend

OK

> xen-watchdog.service - to start xenwatchdogd

OK

> xendomains.service - to run what is essentially a copy of the xendomains
> script with minor changes to take out the Fedora success/failure actions
> which caused problems when I first wrote the systemd file. It might be
> possible to modify the xendomains init.d script so it works in both init.d
> and systemd contexts.

That'd be great.

I see the pld systemd scripts have static paths for binary runs, it'd
be nice if we could use the same strategy by the upstream xencommons
init script of including the variables from

/etc/xen/scripts/hotplugpath.sh

so that the --prefix is respected.

> These don't try to start a qemu-xen instance as the current xencommons
> init.d script does,

Any particular reason for this? I see it only eats up about

> and we would probably need a xencommons.service to stop
> a xencommons init.d script being run.

What would be stopped exactly? If you've split out consoled to its own
control domains and if you don't run the new initial qemu instance
that the upstream xencommons script does start then what's left to
stop? xensored cannot be currently stopped as it seems threads in the
kernel are not kicked to stop using it. This could likely be fixed
though.

  Luis

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