Hi
I gave the new Xen-4.6rc2 a spin on a CentOS 7 virtualisation guest (nested-xen). I haven't yet started testing guests, but rather looked at the install itself.
One issue, I found, was with xenstored.service and the corresponding unit-file:
[root@xencen7ws ~]# systemctl status xenstored xenstored.service - The Xen xenstore Loaded: loaded (/usr/lib/systemd/system/xenstored.service; disabled) Active: active (running) since Tue 2015-09-08 23:13:43 CEST; 13min ago Process: 757 ExecStartPre=/bin/mkdir -p /var/run/xen (code=exited, status=0/SUCCESS) Process: 753 ExecStartPre=/bin/rm -f /var/lib/xenstored/tdb* (code=exited, status=0/SUCCESS) Process: 740 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS) Main PID: 760 (xenstored) CGroup: /system.slice/xenstored.service └─760 /usr/sbin/xenstored
Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: TDB: tdb_open_ex: could not open file /var/lib/xenstored/tdb: No such file or directory Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: Checking store ... Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: Checking store complete. Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: xenstored is ready Sep 08 23:13:43 xencen7ws.virtfinity.local systemd[1]: Started The Xen xenstore.
As you can see, xenstored.service is running, but disabled by the package installation. This is, because xenstored.service apparently got overseen in the source-rpm's spec-file's post runtime/preun runtime. See diff [1] for details.
Also, I think xenstored should write a pidfile. You might consider adding to /usr/lib/systemd/system/xenstored.service: PIDFile=/var/run/xenstored.pid and change ExecStart=/usr/sbin/xenstored to ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
Hope this helps, this is just a quick start. I'll continue checking and reporting during the next days.
Regards, Thomas
[1] diff -u rpmbuild-xen-4.6rc2x-3.el7-org/SPECS/xen.spec rpmbuild-xen-4.6rc2x-3.el7/SPECS/xen.spec --- rpmbuild-xen-4.6rc2x-3.el7-org/SPECS/xen.spec 2015-09-08 18:47:00.000000000 +0200 +++ rpmbuild-xen-4.6rc2x-3.el7/SPECS/xen.spec 2015-09-09 00:06:27.558344410 +0200 @@ -403,6 +403,7 @@ /bin/systemctl enable xen-qemu-dom0-disk-backend.service /bin/systemctl enable xen-init-dom0.service /bin/systemctl enable xenconsoled.service + /bin/systemctl enable xenstored.service # /bin/systemctl enable xendomains.service %endif
@@ -422,6 +423,7 @@ /bin/systemctl disable xen-init-dom0.service /bin/systemctl disable xen-qemu-dom0-disk-backend.service /bin/systemctl disable xenconsoled.service + /bin/systemctl disable xenstored.service # /bin/systemctl disable xendomains.service %endif fi
On Tue, Sep 8, 2015 at 11:25 PM, T.Weyergraf T.Weyergraf@virtfinity.de wrote:
Hi
I gave the new Xen-4.6rc2 a spin on a CentOS 7 virtualisation guest (nested-xen). I haven't yet started testing guests, but rather looked at the install itself.
One issue, I found, was with xenstored.service and the corresponding unit-file:
[root@xencen7ws ~]# systemctl status xenstored xenstored.service - The Xen xenstore Loaded: loaded (/usr/lib/systemd/system/xenstored.service; disabled) Active: active (running) since Tue 2015-09-08 23:13:43 CEST; 13min ago Process: 757 ExecStartPre=/bin/mkdir -p /var/run/xen (code=exited, status=0/SUCCESS) Process: 753 ExecStartPre=/bin/rm -f /var/lib/xenstored/tdb* (code=exited, status=0/SUCCESS) Process: 740 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS) Main PID: 760 (xenstored) CGroup: /system.slice/xenstored.service └─760 /usr/sbin/xenstored
Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: TDB: tdb_open_ex: could not open file /var/lib/xenstored/tdb: No such file or directory Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: Checking store ... Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: Checking store complete. Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: xenstored is ready Sep 08 23:13:43 xencen7ws.virtfinity.local systemd[1]: Started The Xen xenstore.
As you can see, xenstored.service is running, but disabled by the package installation. This is, because xenstored.service apparently got overseen in the source-rpm's spec-file's post runtime/preun runtime. See diff [1] for details.
The Xen documentation (in INSTALL) recommends enabing xen-init-dom0.service, xenconsoled.service, and xen-qemu-dom0-disk-backend.service. I didn't specifically enable xenstored, because I figured that was the "systemd way" -- specify the dependencies, specify what you actually want (i.e., a xen dom0), and let it sort out what actually needs to be started.
Is there a good reason to specifically enable xenstored, even though it will start automatically because of dependencies?
(I really am asking here -- this whole systemd thing is really new to me.)
Also, I think xenstored should write a pidfile. You might consider adding to /usr/lib/systemd/system/xenstored.service: PIDFile=/var/run/xenstored.pid and change ExecStart=/usr/sbin/xenstored to ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
Hope this helps, this is just a quick start. I'll continue checking and reporting during the next days.
I think because systemd doesn't do forking, that it doesn't need a pidfile. In fact, if xenstored detects that it's running under systemd, it will actually ignore the --pid-file directive.
-George
Hey,
What do you mean by doesn't do forking? It allows forking processes if the application can do that. It doesn't fork them by default but ,is it really needed? If xenstored is testing to be run under systemd and not forks itself because of it, that's another thing.
Eliezer
On 09/09/2015 12:40, George Dunlap wrote:
I think because systemd doesn't do forking, that it doesn't need a pidfile. In fact, if xenstored detects that it's running under systemd, it will actually ignore the --pid-file directive.
-George
On Wed, Sep 9, 2015 at 12:25 PM, Eliezer Croitoru eliezer@ngtech.co.il wrote:
Hey,
What do you mean by doesn't do forking? It allows forking processes if the application can do that. It doesn't fork them by default but ,is it really needed? If xenstored is testing to be run under systemd and not forks itself because of it, that's another thing.
Sorry, typing quickly, leaving out important information. :-)
I know very little about systemd, but I know that the Xen project comes with systemd files which have been written by people who should know, and that these are tested on a regular basis.
The xenstored.service file includes this line: Type=notify where other options for "type" might be "forking".
I also know that xenstored is explicitly coded to be able to detect whether it's been run from systemd, and to Do The Right Thing in that situation -- and that actually includes ignoring the pidfile and not forking.
So what I meant was, "xenstored is designed not to do its own forking under systemd".
-George
Eliezer
On 09/09/2015 12:40, George Dunlap wrote:
I think because systemd doesn't do forking, that it doesn't need a pidfile. In fact, if xenstored detects that it's running under systemd, it will actually ignore the --pid-file directive.
-George
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
Sounds pretty much like this is the reality. I have not tested xen yet but I wanted to use it in comparison to KVM. I am working with KVM for quite a while and very happy with it. I have seen that couple xen machines with the same specs as mine has better performance.
Eliezer
On 09/09/2015 17:02, George Dunlap wrote:
So what I meant was, "xenstored is designed not to do its own forking under systemd".
-George
On 09/09/2015 11:40 AM, George Dunlap wrote:
On Tue, Sep 8, 2015 at 11:25 PM, T.Weyergraf T.Weyergraf@virtfinity.de wrote:
Hi
I gave the new Xen-4.6rc2 a spin on a CentOS 7 virtualisation guest (nested-xen). I haven't yet started testing guests, but rather looked at the install itself.
One issue, I found, was with xenstored.service and the corresponding unit-file:
[root@xencen7ws ~]# systemctl status xenstored xenstored.service - The Xen xenstore Loaded: loaded (/usr/lib/systemd/system/xenstored.service; disabled) Active: active (running) since Tue 2015-09-08 23:13:43 CEST; 13min ago Process: 757 ExecStartPre=/bin/mkdir -p /var/run/xen (code=exited, status=0/SUCCESS) Process: 753 ExecStartPre=/bin/rm -f /var/lib/xenstored/tdb* (code=exited, status=0/SUCCESS) Process: 740 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS) Main PID: 760 (xenstored) CGroup: /system.slice/xenstored.service └─760 /usr/sbin/xenstored
Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: TDB: tdb_open_ex: could not open file /var/lib/xenstored/tdb: No such file or directory Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: Checking store ... Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: Checking store complete. Sep 08 23:13:43 xencen7ws.virtfinity.local xenstored[760]: xenstored is ready Sep 08 23:13:43 xencen7ws.virtfinity.local systemd[1]: Started The Xen xenstore.
As you can see, xenstored.service is running, but disabled by the package installation. This is, because xenstored.service apparently got overseen in the source-rpm's spec-file's post runtime/preun runtime. See diff [1] for details.
The Xen documentation (in INSTALL) recommends enabing xen-init-dom0.service, xenconsoled.service, and xen-qemu-dom0-disk-backend.service. I didn't specifically enable xenstored, because I figured that was the "systemd way" -- specify the dependencies, specify what you actually want (i.e., a xen dom0), and let it sort out what actually needs to be started.
Is there a good reason to specifically enable xenstored, even though it will start automatically because of dependencies?
(I really am asking here -- this whole systemd thing is really new to me.)
If the Xen docs (which I haven't checked) state it should not be enabled, it's probably best to follow that advice. xenstored is a bit tricky, as it's not designed to be started/stopped or restarted as a regular service. For my initial report, I checked the stuff I recycled from fedora, which indeed enables xenstored.service and uses a pidfile. From an administrative point of view, I like pidfiles, as they allow to check a service from a script with very little effort. xenstored-pidfiles have been present all the time except until lately (apparently) and I dislike changing things like that without good reason. Suffice to say, that there might be a good reason. I found the initial systemd-related patches to Xen, adding the unit files, but I still need to find the patches changing that behaviour and explaining the reasons.
Also, I think xenstored should write a pidfile. You might consider adding to /usr/lib/systemd/system/xenstored.service: PIDFile=/var/run/xenstored.pid and change ExecStart=/usr/sbin/xenstored to ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
Hope this helps, this is just a quick start. I'll continue checking and reporting during the next days.
I think because systemd doesn't do forking, that it doesn't need a pidfile. In fact, if xenstored detects that it's running under systemd, it will actually ignore the --pid-file directive.
A quick check shows xenstored for systemd to create the socket (in the systemd case). I will read up more code and patches.
For the time being, you are right. Let's not change, what appears to be there for a reason. Once up and running, your packages provide a working xenstored, so there is nothing "broken" by any means.
-George
Regards, Thomas
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
-
Eliezer Croitoru -
George Dunlap -
T.Weyergraf