Re: [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 (o...@aepfle.de) wrote:

> Am Fri, 1 Dec 2017 10:21:46 +
> schrieb Wei Liu :
> 
> > 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Jan Beulich]

>>> Wei Liu  12/01/17 1:30 PM >>>
>On Fri, Dec 01, 2017 at 05:23:16AM -0700, Jan Beulich wrote:
>> >>> On 01.12.17 at 13:15,  wrote:
>> > On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
>> >> >>> On 01.12.17 at 12:48,  wrote:
>> >> > Suppose at one point we split hardware domain and control domain, which
>> >> > one will you call Dom0? Which one will get the flag?
>> >> 
>> >> There can only be one hardware domain, which will continue to
>> >> be the one getting XENFEAT_dom0. There could be any number
>> >> of control domains (perhaps with some coordination between
>> >> them).
>> > 
>> > Right. So XENFEAT_dom0 is not really what Olaf needs. 
>> 
>> Sigh. What does "has access to all the hardware" translate to
>> for you?
>
>That would mean hardware domain.
>
>But Olaf needs to know if some of the services like xenconsoled or
>xenstored should be started, and if some of the special file systems
>should be mounted, right? Those aren't tied to hardware in anyway. In my
>view that's the responsibility of the toolstack control domain.
>
>Can you point me to the start of your discussion with Olaf so that I can
>check what the disagreement between you and Olaf is about?

The start of the discussion is the root of this thread. Olaf somewhere in
the middle pointed to another discussion which you appear to have been
involved in.

I'm also not sure there's actual disagreement here - I was merely pointing
out that strictly following what was written in the description of the patch
there may not be a need to consult /proc/xen, and hence no need to
mount it early.

Jan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

On Fri, Dec 01, Wei Liu wrote:

> What information do you need? For a moment let's skip using the fuzzy
> "Dom0" term and try to be precise. Like "I would like to know if that
> domain has access to all hardware" or something else.

That depends on the .service files. This is the list of openSUSE Tumbleweed:

dev-hugepages.mount:ConditionVirtualization=!private-users
haveged.service:ConditionVirtualization=!container
hv_fcopy_daemon.service:ConditionVirtualization=microsoft
hv_kvp_daemon.service:ConditionVirtualization=microsoft
hv_vss_daemon.service:ConditionVirtualization=microsoft
irqd.service:ConditionVirtualization=!container
ksm.service:ConditionVirtualization=no
lxcfs.service:ConditionVirtualization=!container
mcelog.service:ConditionVirtualization=false
ntp-wait.service:ConditionVirtualization=!container
ntpd.service:ConditionVirtualization=!container
rng-tools.service:ConditionVirtualization=!container
smartd.service:ConditionVirtualization=false
sys-fs-fuse-connections.mount:ConditionVirtualization=!private-users
systemd-random-seed.service:ConditionVirtualization=!container
systemd-timesyncd.service:ConditionVirtualization=!container
vgauthd.service:ConditionVirtualization=vmware
vmblock-fuse.service:ConditionVirtualization=vmware
vmtoolsd.service:ConditionVirtualization=vmware
xendriverdomain.service:ConditionVirtualization=xen

I think the relevant services are ksm,mcelog and smartd. Each one likely
wants the "hardware domain" rather than the "toolstack domain". IMO what
systemd today sees as "dom0" should be set based on "XENFEAT_dom0".

Olaf


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

Am Fri, 1 Dec 2017 12:29:24 +
schrieb Wei Liu :

> But Olaf needs to know if some of the services like xenconsoled or
> xenstored should be started, and if some of the special file systems
> should be mounted, right? Those aren't tied to hardware in anyway. In my
> view that's the responsibility of the toolstack control domain.

No, I did not intent to make use of ConditionVirtualization= in the
xen*.service files in tools/hotplug/Linux/. That variable can not be used
for this purpose, and the patch would not change that.

In case you refer to the "proc-xen.mount" change from a few days/weeks ago,
this was all about avoiding the error when xenfs becomes an "API filesystem".
With this suggested change the existing "proc-xen.mount units would not fail
anymore because /proc/xen is added to the ignore list.

Olaf


pgp7kFBMS_k21.pgp
Description: Digitale Signatur von OpenPGP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Jan Beulich]

>>> On 01.12.17 at 13:15,  wrote:
> On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
>> >>> On 01.12.17 at 12:48,  wrote:
>> > Suppose at one point we split hardware domain and control domain, which
>> > one will you call Dom0? Which one will get the flag?
>> 
>> There can only be one hardware domain, which will continue to
>> be the one getting XENFEAT_dom0. There could be any number
>> of control domains (perhaps with some coordination between
>> them).
> 
> Right. So XENFEAT_dom0 is not really what Olaf needs. 

Sigh. What does "has access to all the hardware" translate to
for you?

Jan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Jan Beulich]

>>> On 01.12.17 at 12:48,  wrote:
> Suppose at one point we split hardware domain and control domain, which
> one will you call Dom0? Which one will get the flag?

There can only be one hardware domain, which will continue to
be the one getting XENFEAT_dom0. There could be any number
of control domains (perhaps with some coordination between
them).

Jan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Jan Beulich]

>>> On 01.12.17 at 11:21,  wrote:
> On Thu, Nov 30, 2017 at 01:35:45AM -0700, Jan Beulich wrote:
>> >>> On 30.11.17 at 09:23,  wrote:
>> > On Wed, Nov 29, Jan Beulich wrote:
>> > 
>> >> Ah, I see. But then still I don't see why at least on half way
>> >> recent Xen /sys/hypervisor/properties/features wouldn't have
>> >> the information you're after (and even more precise, because
>> >> down the road control domain and hardware domain may be
>> >> separate entities).
>> > 
>> > Per discussion in https://github.com/systemd/systemd/pull/6662, the
>> > feature bits should not be used for dom0 detection.
>> 
>> I can't seem to interpret that discussion the way you do. In fact
>> (as I've said before) using the feature flag is more reliable, as it
>> being set implies this is the hardware domain (rather than the
>> more fuzzy "control domain" implied by "control_d").
>> 
>> Wei, your comments there from Oct 27 and 30 are what I think
>> Olaf refers to. Could you clarify this?
>> 
> 
> Judging from the snippet here I don't quite understand what your
> disagreement is. You already said control domain and hardware domain
> could be separate entities in the future.
> 
> The XENFEAT_dom0 flag currently denotes hardware domain. It boils down
> to whether we want Dom0 to mean hardware domain, control domain or just
> "A domain that has domid 0".
> 
> 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 understood it exactly the other way around: The question is
whether to treat things the same as without Xen:
"dom0 has to be handled as "no virtualization" because it has access to
 all hardware, all services depending on "native" have to run in dom0."
Sound like hardware domain to me, not control domain.

Jan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

Am Fri, 1 Dec 2017 10:21:46 +
schrieb Wei Liu :

> 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.

Olaf


pgpexM37QzucI.pgp
Description: Digitale Signatur von OpenPGP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Jan Beulich]

>>> On 30.11.17 at 09:23,  wrote:
> On Wed, Nov 29, Jan Beulich wrote:
> 
>> Ah, I see. But then still I don't see why at least on half way
>> recent Xen /sys/hypervisor/properties/features wouldn't have
>> the information you're after (and even more precise, because
>> down the road control domain and hardware domain may be
>> separate entities).
> 
> Per discussion in https://github.com/systemd/systemd/pull/6662, the
> feature bits should not be used for dom0 detection.

I can't seem to interpret that discussion the way you do. In fact
(as I've said before) using the feature flag is more reliable, as it
being set implies this is the hardware domain (rather than the
more fuzzy "control domain" implied by "control_d").

Wei, your comments there from Oct 27 and 30 are what I think
Olaf refers to. Could you clarify this?

Jan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

On Wed, Nov 29, Jan Beulich wrote:

> Ah, I see. But then still I don't see why at least on half way
> recent Xen /sys/hypervisor/properties/features wouldn't have
> the information you're after (and even more precise, because
> down the road control domain and hardware domain may be
> separate entities).

Per discussion in https://github.com/systemd/systemd/pull/6662, the
feature bits should not be used for dom0 detection.

Olaf


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

On Wed, Nov 29, Jan Beulich wrote:

> But in the description you talk about detect_vm() - by its name that
> doesn't look to care about Dom0, but whether running on top of
> _some_ hypervisor.

dom0 has to be handled as "no virtualization" because it has access to
all hardware, all services depending on "native" have to run in dom0.

Actually, it is spelled with 'z': ConditionVirtualization=
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
https://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html

Olaf


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Jan Beulich]

>>> On 29.11.17 at 17:07,  wrote:
> On Wed, Nov 29, Jan Beulich wrote:
> 
>> But in the description you talk about detect_vm() - by its name that
>> doesn't look to care about Dom0, but whether running on top of
>> _some_ hypervisor.
> 
> dom0 has to be handled as "no virtualization" because it has access to
> all hardware, all services depending on "native" have to run in dom0.

Ah, I see. But then still I don't see why at least on half way
recent Xen /sys/hypervisor/properties/features wouldn't have
the information you're after (and even more precise, because
down the road control domain and hardware domain may be
separate entities).

Jan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

On Wed, Nov 29, Jan Beulich wrote:

> With all of the above, was it considered to check /sys/hypervisor
> alongside with or perhaps even in preference to /proc/xen?

Yes.
/proc/xen/capabilities is the one and only place that indicates a dom0.

Olaf


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Jan Beulich]

>>> On 29.11.17 at 16:54,  wrote:
> On Wed, Nov 29, Jan Beulich wrote:
> 
>> With all of the above, was it considered to check /sys/hypervisor
>> alongside with or perhaps even in preference to /proc/xen?
> 
> Yes.
> /proc/xen/capabilities is the one and only place that indicates a dom0.

But in the description you talk about detect_vm() - by its name that
doesn't look to care about Dom0, but whether running on top of
_some_ hypervisor.

Jan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel