[systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Lennart Poettering]

On Fr, 01.12.17 12:04, Olaf Hering (olaf at aepfle.de) wrote:

> Am Fri, 1 Dec 2017 10:21:46 +0000
> schrieb Wei Liu <wei.liu2 at citrix.com>:
> 
> > In Olaf's case, he cares about knowing whether the domain runs the
> > controlling toolstack, he doesn't care about if it is the hardware
> > domain or not, so my conclusion was using that flag was wrong.
> 
> I think this is not entirely accurate. Right now the term "dom0" is 
> a mix of "has access to host (IO) hardware" and "runs the toolstack".
> 
> ConditionVirtualization= today lacks such details as well.
> "xen" means domU, and "none" is dom0, simply to handle "dom0" like "native"
> so that all services that want access to "host hardware" can start.
> 
> One could argue that passing a PCI device to a domU may also require
> .service files to manage that PCI device in some way. The specifc case
> which triggered all the suggested changes was smartd, which is not
> supposed to run in "VMs". If a SATA card is provided to a domU it may
> be a good idea to monitor the attached disks as well.
> 
> So in some way Jan is correct with his suggestion to use XENFEAT_dom0
> instead of "control_d". I will do some research about when it became available
> and update the patch description.

To make this clear: systemd is only interested in a very high-level
view on things: all it wants to know if we are payload of some kind of
virtualization, or not. We aren't interested in details, and what kind
of virtualization logic Xen precisely deploys is an implementation
detail from our point of view, that we aren't interested in. If
services need to know in all detail what kind of system they run on,
then ConditionVirtualization=/AssertVirtualization= is really not for
them, and they should just run their own code, and figure out things
on their own.

I don't care much where precisely the line is drawn, when a Xen
environment is considered "host" and when "guest", I'll let you guys
figure that out. Only for the latter ConditionVirtualization=guest
should hold, for the latter it should not.

Lennart

-- 
Lennart Poettering, Red Hat