Bug 1290357 - virtlogd is not started/enabled on fresh libvirt install
Summary: virtlogd is not started/enabled on fresh libvirt install
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-release
Version: 24
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Dennis Gilmore
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1382301 1432335 (view as bug list)
Depends On: 1291940
Blocks: 1318902 1325503
TreeView+ depends on / blocked
 
Reported: 2015-12-10 10:25 UTC by jean-christophe manciot
Modified: 2017-03-25 00:42 UTC (History)
36 users (show)

Fixed In Version: fedora-release-24-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1325503 (view as bug list)
Environment:
Last Closed: 2016-06-08 01:22:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Building Libvirt 1.3.0 Log (184.94 KB, text/plain)
2015-12-12 15:07 UTC, jean-christophe manciot
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1291940 0 high CLOSED SELinux is preventing systemd from 'create' accesses on the unix_stream_socket Unknown. 2021-02-22 00:41:40 UTC

Internal Links: 1291940

Description jean-christophe manciot 2015-12-10 10:25:58 UTC
Description of problem:
----------------------
Error starting domain: Failed to connect socket to '/var/run/libvirt/virtlogd-sock': No such file or directory

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 90, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 126, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1402, in startup
    self._backend.create()
  File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 1029, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: Failed to connect socket to '/var/run/libvirt/virtlogd-sock': No such file or directory

Version-Release number of selected component (if applicable):
------------------------------------------------------------
virt-manager 1.3.1
libvirt 1.3.0

Additional info:
---------------
Ubuntu Server 15.10

Comment 1 jean-christophe manciot 2015-12-10 10:29:49 UTC
Everything works fine with libvirt 1.2.20, except for this another unsolved (and dismissed?) libvirt issue: https://bugzilla.redhat.com/show_bug.cgi?id=1275468, but I have found a workaround for this one.

Comment 2 Cole Robinson 2015-12-10 15:35:44 UTC
libvirt 1.3.0 added a new mandatory service, virtlogd. so you'll need to enable that with service/systemctl first. RPM packaging bits would handle it but we don't autostart services via make install

Comment 3 Jiri Denemark 2015-12-10 16:26:02 UTC
Alternatively, you can set stdio_handler="file" in /etc/libvirt/qemu.conf to get the behavior of libvirt < 1.3.0, but you'd lose the functionality which virtlogd provides.

Comment 4 jean-christophe manciot 2015-12-11 11:26:49 UTC
I can see some virtlogd.*.in files in the git/src/logging, but it seems they are not installed; and there's no release notes or documentation about where they should be installed.
I suppose the virtlogd.init.in should be copied in /etc/init.d. What about the others?

Comment 5 Cole Robinson 2015-12-11 17:12:49 UTC
how are you installing? what's the configure line you're using? maybe grep the install output and see where virtlogd files are going, the build system could be wrong

Comment 6 jean-christophe manciot 2015-12-11 19:27:18 UTC
Nothing too special I guess:

	./autogen.sh
	./configure --without-wireshark-dissector \
            	    --with-openssl \
	    	    --without-apparmor \
	    	    --without-apparmor-mount \
	    	    --without-apparmor-profiles \
	    	    --without-secdriver-apparmor \
	    	    --prefix=/usr --sysconfdir=/etc --localstatedir=/var

	make
	sudo make install

Comment 7 jean-christophe manciot 2015-12-12 15:06:14 UTC
From make:
...
  CC       logging/virtlogd-log_daemon.o
  CC       logging/virtlogd-log_daemon_config.o
  CC       logging/virtlogd-log_daemon_dispatch.o
  CC       logging/virtlogd-log_handler.o
  CC       logging/virtlogd-log_protocol.o
  CCLD     virtlogd
...

From sudo make install:
...
 /bin/mkdir -p '/usr/sbin'
  /bin/bash ../libtool   --mode=install /usr/bin/install -c virtlockd virtlogd '/usr/sbin'
libtool: install: /usr/bin/install -c virtlockd /usr/sbin/virtlockd
libtool: install: /usr/bin/install -c virtlogd /usr/sbin/virtlogd
 /bin/mkdir -p '/usr/share/augeas/lenses'
 /usr/bin/install -c -m 644 qemu/libvirtd_qemu.aug lxc/libvirtd_lxc.aug locking/libvirt_lockd.aug locking/virtlockd.aug logging/virtlogd.aug '/usr/share/augeas/lenses'
 /bin/mkdir -p '/usr/share/augeas/lenses/tests'
 /usr/bin/install -c -m 644 test_libvirtd_qemu.aug test_libvirtd_lxc.aug test_libvirt_lockd.aug test_virtlockd.aug test_virtlogd.aug '/usr/share/augeas/lenses/tests'
 /bin/mkdir -p '/etc/libvirt'
 /usr/bin/install -c -m 644 libvirt.conf libvirt-admin.conf qemu/qemu.conf lxc/lxc.conf locking/virtlockd.conf logging/virtlogd.conf '/etc/libvirt'
/bin/mkdir -p "/var/lib/libvirt/lockd"
...
 /bin/mkdir -p '/usr/share/man/man8'
 /usr/bin/install -c -m 644 virtlockd.8 virtlogd.8 '/usr/share/man/man8'
 /bin/mkdir -p '/usr/lib/libvirt/connection-driver'
...

And that's it!

The whole log has been attached.

Comment 8 jean-christophe manciot 2015-12-12 15:07:38 UTC
Created attachment 1105062 [details]
Building Libvirt 1.3.0 Log

Comment 9 Adam Williamson 2016-01-12 23:54:17 UTC
"RPM packaging bits would handle it"

O RLY? I hit this issue after updating my Rawhide machine, and here's what systemctl status thinks:

[adamw@adam nightlies]$ sudo systemctl status virtlogd.service
● virtlogd.service - Virtual machine log manager
   Loaded: loaded (/usr/lib/systemd/system/virtlogd.service; indirect; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:virtlogd(8)
           http://libvirt.org

so RPM bits perhaps *could* handle it, but they don't seem to be *actually* handling it, at least yet...

Comment 10 Adam Williamson 2016-01-12 23:59:47 UTC
Also, virtlogd.socket cannot start, SELinux is preventing it. https://bugzilla.redhat.com/show_bug.cgi?id=1291940

Comment 11 Fangge Jin 2016-03-29 10:26:49 UTC
Hello, is there any news about this bug? 
When I install libvirt for the first time, I have to start both libvirtd and virtlogd service. If I only start libvirtd service, guest can't start successfully as it cant' connect to virtlogd socket. 
And many of us are confused by this error when testing vdsm and virt-manager. We think it will be nice to activate virtlogd.socket automatically when start libvirtd. Can this be done?
Thank you

Comment 12 Andrey Motoshkov 2016-04-05 19:16:32 UTC
Same behavior with libvirt-1.3.2-3.fc24.x86_64: service virtlogd should be started separately. Steps to reproduce:
1) Disable libvirtd.service: systemctl disable libvirtd.service
2) Reboot 
3) Start libvirtd from terminal: systemctl start libvirtd
4) Start your VM: virsh start VMname

Problem:
VM domain won't start. Error: "error: Failed to start domain VMname
error: Failed to connect socket to '/var/run/libvirt/virtlogd-sock': No such file or directory"

Expected:
VM domain start successfully.

Workaround:
1) Start virtlogd: systemctl start virtlogd
2) Start your VM

Comment 13 Cole Robinson 2016-04-07 22:36:28 UTC
So it looks like virtlogd will be started+enabled when libvirt is _upgraded_, but not on a fresh libvirt install:

commit da054f35ab3289c9114bc320338f14b3a88709b2
Author: Daniel P. Berrange <berrange>
Date:   Mon Dec 7 12:48:04 2015 +0000

    rpm: explicitly enable & start virtlogd on install


Though it seems like virtlogd.socket _is_ unconditionally enabled, though it certainly doesn't look like socket activation is working. I didn't dig deeper. danpb, do you have any ideas?

Comment 14 Cole Robinson 2016-04-08 20:57:48 UTC
So I'm not entirely sure what to do here, re-assigning to systemd for more info (and it may need an addition to the default service list)

Background: libvirt 1.3.0 added a new daemon, virtlogd, that allows multiplexing VM logging. The default package config requires use of this daemon, but the user can turn it off in /etc/libvirt/qemu.conf. If the daemon isn't running, all VM startup will fail. Also note libvirt is on the 90-default.preset 'allowed to start by default' whitelist

What's the ideal solution here?

* use socket activation? the daemon is started on demand if the libvirt config actually needs it. this sounds ideal but the Fedora guidelines make it sound like socket activation is a no no
* add a dependency in libvirtd.service? but virtlogd isn't strictly required by libvirtd so I'm not sure if this is ideal
* add virtlogd to 90-default.preset so it's enabled/started by default?
* something else?

Comment 15 Zbigniew Jędrzejewski-Szmek 2016-04-08 21:09:22 UTC
(In reply to Cole Robinson from comment #14)
> So I'm not entirely sure what to do here, re-assigning to systemd for more
> info (and it may need an addition to the default service list)
> 
> Background: libvirt 1.3.0 added a new daemon, virtlogd, that allows
> multiplexing VM logging. The default package config requires use of this
> daemon, but the user can turn it off in /etc/libvirt/qemu.conf. If the
> daemon isn't running, all VM startup will fail. Also note libvirt is on the
> 90-default.preset 'allowed to start by default' whitelist

Strictly speaking, it's not 'allowed to start by default' but 'will be started by default' whitelist.

> What's the ideal solution here?
> 
> * use socket activation? the daemon is started on demand if the libvirt
> config actually needs it. this sounds ideal but the Fedora guidelines make
> it sound like socket activation is a no no
Yeah, socket activation sounds like the way to go.
The way this should work is that "enable virtlogd.socket" is added to 90-default.preset.

I'm not aware of guidelines forbidding socket activation. Can you point me to the place where there's anything said about that?

Comment 16 Cole Robinson 2016-04-08 22:15:43 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #15)
> (In reply to Cole Robinson from comment #14)
> 
> > What's the ideal solution here?
> > 
> > * use socket activation? the daemon is started on demand if the libvirt
> > config actually needs it. this sounds ideal but the Fedora guidelines make
> > it sound like socket activation is a no no
> Yeah, socket activation sounds like the way to go.
> The way this should work is that "enable virtlogd.socket" is added to
> 90-default.preset.
> 

Okay, I'll test it and ensure the libvirt side is working when virtlogd.socket is enabled.

> I'm not aware of guidelines forbidding socket activation. Can you point me
> to the place where there's anything said about that?

https://fedoraproject.org/wiki/Packaging:Systemd#Socket_activation

Lines like "Simila to inetd, using socket activation for on-demand loading will impose a startup time penalty so we currently do not use this feature in Fedora." and " Since Fedora currently doesn't want any services to do on-demand loading, all socket activated services must autostart. "

Comment 17 Zbigniew Jędrzejewski-Szmek 2016-04-08 23:55:42 UTC
> Okay, I'll test it and ensure the libvirt side is working when virtlogd.socket is enabled.

Wait a second. Is virtlogd.socket useful on it's own, or is only used when libvirtd.service is running? If the latter, then it'd make sense to simply pull virtlogd.socket from libvirtd.service.

> https://fedoraproject.org/wiki/Packaging:Systemd#Socket_activation

Ah, OK. https://fedorahosted.org/fpc/ticket/618 duly filed.

Comment 18 Cole Robinson 2016-04-09 00:29:51 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #17)
> > Okay, I'll test it and ensure the libvirt side is working when virtlogd.socket is enabled.
> 
> Wait a second. Is virtlogd.socket useful on it's own, or is only used when
> libvirtd.service is running? If the latter, then it'd make sense to simply
> pull virtlogd.socket from libvirtd.service.
> 

It's kind of subtle... libvirt will setup VMs to use virtlogd, but once the VMs are running the idea is that libvirtd can be stopped and the VMs will continue to work fine, talking to virtlogd. So virtlogd is an indepdendent entity, but the only way it will ever be used is via VMs that libvirt starts.

The issue with adding the libvirt dep is that libvirt doesn't strictly require virtlogd, just the default libvirt config requires it. Not sure if that warrants stuffing a dep in the systemd unit or not. socket activation sounds ideal IMO

Comment 19 Zbigniew Jędrzejewski-Szmek 2016-04-09 00:54:09 UTC
OK, so the original plan of adding virtlogd.socket to 90-default.presets sounds right.

https://pagure.io/fedora-release/pull-request/43
https://pagure.io/fedora-release/pull-request/44

Comment 20 jean-christophe manciot 2016-04-09 07:38:36 UTC
For the time being, as pointed out by @Jiri Denemark (https://bugzilla.redhat.com/show_bug.cgi?id=1290357#c3), it is possible to disable virtlogd without affecting VMs life, including with the latest libvirt 1.3.3:
- stdio_handler="file" in /etc/libvirt/qemu.conf
- restart libvirtd

systemctl status libvirt-bin
● libvirt-bin.service - Virtualization daemon
   Loaded: loaded (/lib/systemd/system/libvirt-bin.service; enabled; vendor preset: enabled)
   Active: active (running) since sam. 2016-04-09 08:22:58 CEST; 51min ago
     Docs: man:libvirtd(8)
           http://libvirt.org
 Main PID: 7388 (libvirtd)
   Memory: 24.9M
      CPU: 948ms
   CGroup: /system.slice/libvirt-bin.service
           ├─2797 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/virl-data-flat1.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_lea...
...
file=/var/lib/libvirt/dnsmasq/virtual-mgt-5.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_lease...
           ├─7181 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/virtual-mgt-5.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_lease...
           └─7388 /usr/sbin/libvirtd
...
# systemctl status virtlogd
● virtlogd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

For example:
virsh connect qemu:///system
virsh list
 Id    Name                           State
----------------------------------------------------
 1     KVM-Ubuntu-Gnome-Server-15.10  running
 2     KVM-Windows-10                 running

Comment 21 Zbigniew Jędrzejewski-Szmek 2016-06-08 01:22:26 UTC
My pull request went in and this is fixed with the latest fedora-release.

Comment 22 Dimitris 2016-07-03 01:55:22 UTC
Just upgraded F23->F24 and my qemu:///session VMs won't start, apparently due to this problem.  Any guidance/workaround?  virtlogd.s{ervice,ocket} are not known in the user context:

$ systemctl --user status virtlogd.service
● virtlogd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

Comment 23 Dimitris 2016-07-03 05:20:12 UTC
Did some reading up and I think my systemd user-unit comment was on the wrong track above; sorry about that noise.

FWIW I managed to get the guests running after working around a couple of regressions (one workaround reduces security).

Details in bug 1352263 and bug 1352265

Comment 24 Thomas Jarosch 2017-02-10 17:58:37 UTC
Cross-upgraded from F22 to F25, virtlogd was not enabled by default.
Therefore some VMs didn't start anymore on boot.

A simple "systemctl enable virtlogd" fixed the issue.

Comment 25 Robert Story 2017-03-09 17:05:08 UTC
New F25 install with all updates here. installws virtualization, and virtlogd is not started or even set to start (vendor preset: disabled):

# service virtlogd status
Redirecting to /bin/systemctl status  virtlogd.service
● virtlogd.service - Virtual machine log manager
   Loaded: loaded (/usr/lib/systemd/system/virtlogd.service; indirect; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:virtlogd(8)
           http://libvirt.org

Comment 26 Cole Robinson 2017-03-13 22:25:09 UTC
There's been intermittent reports that this is still an 'issue' like Comment #25 and I just confirmed. Fresh f24 machine, install libvirt-daemon-kvm: afterwards, virtlogd.socket and libvirtd.service are both _enabled_ but not _running_

Zbigniew, is this expected? Is there a systemd macro/snippet we should be using to start virtlogd.socket on first install? Or is this not something packages are supposed to do?

Comment 27 Cole Robinson 2017-03-13 22:34:40 UTC
*** Bug 1382301 has been marked as a duplicate of this bug. ***

Comment 28 Stephen Gallagher 2017-03-13 22:53:00 UTC
(In reply to Cole Robinson from comment #26)
> There's been intermittent reports that this is still an 'issue' like Comment
> #25 and I just confirmed. Fresh f24 machine, install libvirt-daemon-kvm:
> afterwards, virtlogd.socket and libvirtd.service are both _enabled_ but not
> _running_
> 
> Zbigniew, is this expected? Is there a systemd macro/snippet we should be
> using to start virtlogd.socket on first install? Or is this not something
> packages are supposed to do?

So, this is controlled by the presence or absence of virtlogd.socket or virtlogd.service in the systemd presets. Currently, Fedora 25+ has virtlogd.socket enabled. It's not currently set for Fedora 24, so that's why you're seeing the behavior that you are.

If you need that to be working on Fedora 24, please see https://fedoraproject.org/wiki/Packaging:DefaultServices#How_to_enable_a_service_by_default and file a BZ at https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&format=fedora-systemd-request which someone will process.

That said, looking at your specfile, I suspect you're not following the proper guidelines for installing a systemd service on Fedora and you're actually explicitly calling `/bin/systemctl enable <units>` in the %post script, which is a no-no. I'm having trouble parsing all of the conditionals, but that might explain why it's marked as "enabled".

Please see https://fedoraproject.org/wiki/Packaging:Scriptlets?rd=Packaging:ScriptletSnippets#Systemd for the proper commands to use. Once the preset file is updated, everything should work as expected.

Comment 29 Zbigniew Jędrzejewski-Szmek 2017-03-13 23:57:38 UTC
(In reply to Stephen Gallagher from comment #28)
> So, this is controlled by the presence or absence of virtlogd.socket or
> virtlogd.service in the systemd presets. Currently, Fedora 25+ has
> virtlogd.socket enabled. It's not currently set for Fedora 24, so that's why
> you're seeing the behavior that you are.
Hm, I think it *is* enabled for F24, see 
https://pagure.io/fedora-release/blob/f24/f/90-default.preset#_184.

(But see below).

> That said, looking at your specfile, I suspect you're not following the
> proper guidelines for installing a systemd service on Fedora and you're
> actually explicitly calling `/bin/systemctl enable <units>` in the %post
> script, which is a no-no. I'm having trouble parsing all of the
> conditionals, but that might explain why it's marked as "enabled".
> 
> Please see
> https://fedoraproject.org/wiki/Packaging:Scriptlets?rd=Packaging:
> ScriptletSnippets#Systemd for the proper commands to use. Once the preset
> file is updated, everything should work as expected.
I think the scriptlets *are* OK. Indeed it's hard to go through all the conditionals, but on F25 rpmspec -P shows:

------------------------&<---------------------------------
%post daemon
if [ $1 -eq 1 ] ; then 
        # Initial installation 
        systemctl --no-reload preset virtlockd.socket virtlogd.socket libvirtd.service >/dev/null 2>&1 || : 
fi 

%preun daemon
if [ $1 -eq 0 ] ; then 
        # Package removal, not upgrade 
        systemctl --no-reload disable --now libvirtd.service virtlogd.socket virtlogd.service virtlockd.socket virtlockd.service > /dev/null 2>&1 || : 
fi 

%postun daemon
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
if [ $1 -ge 1 ] ; then
    /bin/systemctl reload-or-try-restart virtlockd.service >/dev/null 2>&1 || :
    /bin/systemctl reload-or-try-restart virtlogd.service >/dev/null 2>&1 || :
    /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || :
fi

# In upgrade scenario we must explicitly enable virtlockd/virtlogd
# sockets, if libvirtd is already enabled and start them if
# libvirtd is running, otherwise you'll get failures to start
# guests
%triggerpostun daemon -- libvirt-daemon < 1.3.0
if [ $1 -ge 1 ] ; then
        /bin/systemctl is-enabled libvirtd.service 1>/dev/null 2>&1 &&
            /bin/systemctl enable virtlogd.socket || :
        /bin/systemctl is-active libvirtd.service 1>/dev/null 2>&1 &&
            /bin/systemctl start virtlogd.socket || :
fi
------------------------>&---------------------------------
That's OK, except for the %postun part. Please replace it with
%systemd_postun_with_restart virtlogd.service virtlockd.service libvirtd.service

(The reason why restart is wanted instead of reload is that we want to restart
the process to get new code running. Reloading does not achieve that.
There's no need to do systemctl daemon-reload since F25 too.)

And drop all Requires: systemd and references to systemd-units and systemd-sysv,
and only keep:
BuildRequires: systemd
%systemd_requires


Now, back to the issue. Comment #25 is a red herring. virtlogd.service should *not* be enabled. It's virtlod.socket which is supposed to be enabled. And the preset is correct for that:
$ grep virtlogd.socket /usr/lib/systemd/system-preset/*
/usr/lib/systemd/system-preset/90-default.preset:enable virtlogd.socket

So what I think is happening, at least in some cases, is that people are upgrading the package, and the 'systemctl preset' call does not enable the socket for them. Maybe the conditional in %triggerpostun needs to be changed to a higher version?

Comment 30 Zbigniew Jędrzejewski-Szmek 2017-03-14 00:16:06 UTC
For testing, I just installed F24 and F25 from scratch, with libvirt-daemon. In both cases I have:
libvirtd.service → enabled
virtlogd.socket → enabled
virtlogd.service → indirect

Comment 31 Cole Robinson 2017-03-14 00:39:44 UTC
Thanks for the info. Comment #30 is what I'm seeing as well. 

But my question from Comment #26 still stands: can/should we be doing anything different on fresh install, so virtlogd.socket is not just enabled but also running/active? Or is that against Fedora policy?

(Maybe libvirtd.service should add Wants=virtlogd.socket, so users just have to 'systemctl start libvirtd.service' and the socket will start as well. Users already seem to expect to have to run libvirtd on first install)

Comment 32 Zbigniew Jędrzejewski-Szmek 2017-03-14 03:07:10 UTC
If by "on fresh install" you mean immediately after package installation, but before reboot, then yes, the policy is that daemons must not start.

> Maybe libvirtd.service should add Wants=virtlogd.socket ]...]
> Users already seem to expect to have to run libvirtd on first install

That's an option, but there are users who have stdio_handler="file" and it's legitimate to run without virtlogd.socket. If you know to start libvirt.service, you should also know to start virtlogd.socket... I guess it's a question of how common it is not to run virtlogd.service on purpose. If it's rare, then it might make sense to add Wants=virtlogd.socket to avoid issues.

(If you *do* decide to add it, please add it as a symlink /usr/lib/systemd/system/libvirt.service.wants/virtlogd.socket → ../virtlogd.socket. In F26+ systemd allows masking of such symlinks, so users will be able to mask the dependency with a symlink /etc/systemd/system/libvirtd.service.wants/virtlogd.socket → /dev/null it they don't need the dependency.)

Comment 33 Tomas Jelinek 2017-03-22 11:01:10 UTC
*** Bug 1432335 has been marked as a duplicate of this bug. ***

Comment 34 Cole Robinson 2017-03-25 00:42:55 UTC
Looks like upstream libvirt already has the Wants=virtlogd.socket change, so I opened a libvirt bug to track backporting it

https://bugzilla.redhat.com/show_bug.cgi?id=1435855


Note You need to log in before you can comment on or make changes to this bug.