Description of problem: libvirt's virSystemdCreateMachine (src/util/virsystemd.c) calls the systemd API `CreateMachineWithNetwork` via D-Bus to register machines. It works fine until systemd 225. However, with systemd 229, the `Before` property that is passed isn't accepted anymore and thus, makes the registration and creation of machines to fail. Version-Release number of selected component (if applicable): libvirt 1.2.17 (13.el7_2.5) systemd 229 (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS -ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN) Steps to Reproduce: 0. Get an Ubuntu Xenial VM 1. apt-get install qemu-kvm libvirt-bin 2. Follow instructions at https://wiki.ubuntu.com/SergeHallyn_libvirtnest , in particular: a. wget http://people.canonical.com/~serge/cdboot.xml b. wget -O mini.iso http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/mini.iso c. qemu-img create cdboot.img 1G d. virsh define cdboot.xml e. virsh start cdboot 3. now apt-get install systemd-container 4. now virsh destroy cdboot; virsh start cdboot; it should fail (https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1529079/comments/39) Actual results: libvirtError: Cannot set property Before, or unknown property. Expected results: - The machine should be started properly: a. `Before` shouldn't be passed, b. `After` should probably not be passed either, - A systemd registration failure should maybe not be critical. Additional info: Issue reproduced on Ubuntu Xenial & CoreOS >1010.
Passing Before & After properties is absolutely required in order to get correct shutdown ordering - ie we need systemd to run libvirt-guests. I've confirmed testing on Fedora 24 with systemd 229 and see no failure, so I don't believe this is a libvirt bug. More likely it is a distro specific systemd bug or deployment mistake (eg perhaps missing libvirt-guests.service unit file).
I haven't been able to spot anything in either the CoreOS or Fedora systemd patch sets that would impact this one way or the other so far, will need to dig further.
Ok, found some suspicious behavior in systemd. The distinction may be whether or not the 'After' dependency refers to an existing unit or not. On CoreOS it is entirely likely libvirtd.service doesn't exist or has a different name. I'm not sure about the Ubuntu case. Also the order if After/Before in the properties list is significant. Using Before/After appears to work. Both dependencies do not exist, but fails only when After is first: # busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 \ org.freedesktop.systemd1.Manager StartTransientUnit 'ssa(sv)a(sa(sv))' \ test7.slice replace 2 After as 1 other.target Before as 1 fake.target 0 Cannot set property Before, or unknown property. # busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 \ org.freedesktop.systemd1.Manager StartTransientUnit 'ssa(sv)a(sa(sv))' \ test7.slice replace 2 Before as 1 fake.target After as 1 other.target 0 o "/org/freedesktop/systemd1/job/23660" Whether or not the Before dependency exists never matters. Quentin: so at least this hints at a workaround, either create a dummy libvirtd.service unit file or run the container with that unit name. Or if the container doesn't make sense to run as libvirtd.service maybe a unit alias is sufficient. Alternate workaround: patch libvirt to swap the order of those two properties. Real fix: figure out what on earth is going on in systemd, but that's all the brain power I can spend on this at the moment.
See https://www.redhat.com/archives/libvir-list/2016-June/msg02163.html
See https://github.com/systemd/systemd/pull/3676
Re-opening since F24 has the version of systemd with the flaw and so could benefit from the patch
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.