[Group.of.nepali.translators] [Bug 1680384] Re: libvirt-qemu apparmor profiles misses several important entries
** Changed in: libvirt (Debian) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1680384 Title: libvirt-qemu apparmor profiles misses several important entries Status in libvirt package in Ubuntu: Fix Released Status in libvirt source package in Trusty: Incomplete Status in libvirt source package in Xenial: Fix Released Status in libvirt source package in Yakkety: Fix Released Status in libvirt source package in Zesty: Fix Released Status in libvirt package in Debian: Fix Released Bug description: [Impact] * Attaching of virtual functions (SR-IOV) not possible without manually modification of apparmor rules * libvirt/qemu guest logfiles can not state the program that sent the shutdown signal * on ppc64el when starting on SMT enabled it failes (expected) but does not present the hint about SMT being the reasons that was added in >=zesty * various apparmor denials in the log hide other issues * Fix by opening up apparmor rules as needed for these use-cases [Test Case] * The rules covere a set of use cases, outlining them all here. Some only apply to >=Zesty, so I mark each subtest with release names. * All start with "Spawn a kvm guest e.g. via uvtool-libvirt" * A) >=Xenial - shutdown message - A1 - start the guest - A2 - stop the guest - A3 - check the log in /var/log/libvirt/qemu/.log - A-check: without the fix the log ends with With the fix it shall contain the name of the process stopping it instead of. So libvirt shutdown will show libvirtd, kill from bash shows bash, ...) * B) >=Xenial - B1 - prepare a hotplug xml and a SR-IOV device - that depends on your system, one example is outlined here: # Prep VFs and attach $ echo 4 | sudo tee /sys/bus/pci/devices/0005\:01\:00.0/sriov_numvfs $ sudo modprobe vfio-pci $ lspci -n -s 0005:01:01.3 0005:01:01.3 0200: 10df:e228 (rev 10) $ cat VF-5.1.1.3.xml - B2 until bug 1679704 is fixed you need to manually increase the locked memory limit of the qemu process before going on - B3 attach the device $ virsh attach-device z-test VF-5.1.1.3.xml - B-check: without the fix it will fail for a set of apparmor denials with the fix the attaching will succeed * C) >=Zesty - C1 - on a ppc64el system start and stop a guest - C-check: without the fix apparmor will hold many denies for ppc64_cpu and/or accessing /sys/devices/system/cpu/... With the fix not only the denies are gone, but also if you run on a system with SMT enabled (kvm will fail there) it will report to you in the log about "Error: You must disable SMT ..." [Regression Potential] * We are only further "opening up" the current apparmor profiles. So we should not end up affecting existing use cases by new blocks. * There is a very slight chance that due to accesses being allowed follow on actions are triggered which people are not used to like "the VF hot attach actually working". So if one relied on it not working it will be different for them. * Further I made some brainstorming on the potential effects but the only other one that came to my mind being a regression of some sort is that it now correctly states what send the shutdown signal. So when qemu did not end by itself (guest stops) but is stopped (shutdown) the old message was: terminating on signal 15 from pid 22938 () And now will be like: terminating on signal 15 from pid 7714 (/usr/sbin/libvirtd) For the hopefully super unlikely case that someone e.g. grepped for unknown here it might be a regression. And making that message more useful (along with getting rid of the associated aa deny is part of the intended fix). [Other Info] * Tested manually and via regression tests in advance on bileto tickets. So all are green there now, there were two unrelated in some dep8 tests due to what seems transient network timeouts (worked on retry) - if showing up in proposed as well we will likely have to retrigger the tests until good. Latest ticket for these to look at sniff builds: => https://bileto.ubuntu.com/#/ticket/2738 * Upload will be directly, since in some of the releases I will need dpdk-genversion -v which bileto does not support (and it doesn't support publishing selective releases) yet I wanted to show the extra tests and checks made and therefore using bileto was beneficial even if eventually uploading "old
[Group.of.nepali.translators] [Bug 1680384] Re: libvirt-qemu apparmor profiles misses several important entries
Christian: This bug now hit debian-testing (see http://209.132.184.41/logs/pull-8219-20171206-214646-d2e9e141-verify- debian-testing/log.html#2). Is there an upstream bug/patch mail for reference, or are these Debian/Ubuntu downstream rules? ** Bug watch added: Debian Bug tracker #878203 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878203 ** Also affects: libvirt (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878203 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1680384 Title: libvirt-qemu apparmor profiles misses several important entries Status in libvirt package in Ubuntu: Fix Released Status in libvirt source package in Trusty: Incomplete Status in libvirt source package in Xenial: Fix Released Status in libvirt source package in Yakkety: Fix Released Status in libvirt source package in Zesty: Fix Released Status in libvirt package in Debian: Unknown Bug description: [Impact] * Attaching of virtual functions (SR-IOV) not possible without manually modification of apparmor rules * libvirt/qemu guest logfiles can not state the program that sent the shutdown signal * on ppc64el when starting on SMT enabled it failes (expected) but does not present the hint about SMT being the reasons that was added in >=zesty * various apparmor denials in the log hide other issues * Fix by opening up apparmor rules as needed for these use-cases [Test Case] * The rules covere a set of use cases, outlining them all here. Some only apply to >=Zesty, so I mark each subtest with release names. * All start with "Spawn a kvm guest e.g. via uvtool-libvirt" * A) >=Xenial - shutdown message - A1 - start the guest - A2 - stop the guest - A3 - check the log in /var/log/libvirt/qemu/.log - A-check: without the fix the log ends with With the fix it shall contain the name of the process stopping it instead of. So libvirt shutdown will show libvirtd, kill from bash shows bash, ...) * B) >=Xenial - B1 - prepare a hotplug xml and a SR-IOV device - that depends on your system, one example is outlined here: # Prep VFs and attach $ echo 4 | sudo tee /sys/bus/pci/devices/0005\:01\:00.0/sriov_numvfs $ sudo modprobe vfio-pci $ lspci -n -s 0005:01:01.3 0005:01:01.3 0200: 10df:e228 (rev 10) $ cat VF-5.1.1.3.xml - B2 until bug 1679704 is fixed you need to manually increase the locked memory limit of the qemu process before going on - B3 attach the device $ virsh attach-device z-test VF-5.1.1.3.xml - B-check: without the fix it will fail for a set of apparmor denials with the fix the attaching will succeed * C) >=Zesty - C1 - on a ppc64el system start and stop a guest - C-check: without the fix apparmor will hold many denies for ppc64_cpu and/or accessing /sys/devices/system/cpu/... With the fix not only the denies are gone, but also if you run on a system with SMT enabled (kvm will fail there) it will report to you in the log about "Error: You must disable SMT ..." [Regression Potential] * We are only further "opening up" the current apparmor profiles. So we should not end up affecting existing use cases by new blocks. * There is a very slight chance that due to accesses being allowed follow on actions are triggered which people are not used to like "the VF hot attach actually working". So if one relied on it not working it will be different for them. * Further I made some brainstorming on the potential effects but the only other one that came to my mind being a regression of some sort is that it now correctly states what send the shutdown signal. So when qemu did not end by itself (guest stops) but is stopped (shutdown) the old message was: terminating on signal 15 from pid 22938 () And now will be like: terminating on signal 15 from pid 7714 (/usr/sbin/libvirtd) For the hopefully super unlikely case that someone e.g. grepped for unknown here it might be a regression. And making that message more useful (along with getting rid of the associated aa deny is part of the intended fix). [Other Info] * Tested manually and via regression tests in advance on bileto tickets. So all are green there now, there were two unrelated in some dep8 tests due to what seems transient network timeouts (worked on retry) - if showing up in proposed as well we will likely have to retrigger the tests until good. Latest
[Group.of.nepali.translators] [Bug 1680384] Re: libvirt-qemu apparmor profiles misses several important entries
This bug was fixed in the package libvirt - 1.3.1-1ubuntu10.10 --- libvirt (1.3.1-1ubuntu10.10) xenial; urgency=medium * Fix bad SRU backport to match apparmor structure of libvirt in Xenial (LP: #1680384) - drop d/p/ubuntu/apparmor-shutdown.patch as the libvirt code here doesn't trigger it. - drop d/p/ubuntu/apparmor-vfio.patch as xenial still uses profiles from debian/apparmor/ - apply content of apparmor-vfio.patch to debian/apparmor/libvirt-qemu to fix the actual issue. libvirt (1.3.1-1ubuntu10.9) xenial; urgency=medium * Add missing apparmor profile entries (LP: #1680384) - debian/patches/ubuntu/apparmor-vfio.patch: apparmor: add /dev/vfio for vf (hot) attach - debian/patches/ubuntu/apparmor-shutdown.patch: apparmor: allow to parse cmdline of the pid that send the shutdown signal -- Christian Ehrhardt Tue, 16 May 2017 12:38:02 +0200 ** Changed in: libvirt (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1680384 Title: libvirt-qemu apparmor profiles misses several important entries Status in libvirt package in Ubuntu: Fix Released Status in libvirt source package in Trusty: Incomplete Status in libvirt source package in Xenial: Fix Released Status in libvirt source package in Yakkety: Fix Released Status in libvirt source package in Zesty: Fix Released Bug description: [Impact] * Attaching of virtual functions (SR-IOV) not possible without manually modification of apparmor rules * libvirt/qemu guest logfiles can not state the program that sent the shutdown signal * on ppc64el when starting on SMT enabled it failes (expected) but does not present the hint about SMT being the reasons that was added in >=zesty * various apparmor denials in the log hide other issues * Fix by opening up apparmor rules as needed for these use-cases [Test Case] * The rules covere a set of use cases, outlining them all here. Some only apply to >=Zesty, so I mark each subtest with release names. * All start with "Spawn a kvm guest e.g. via uvtool-libvirt" * A) >=Xenial - shutdown message - A1 - start the guest - A2 - stop the guest - A3 - check the log in /var/log/libvirt/qemu/.log - A-check: without the fix the log ends with With the fix it shall contain the name of the process stopping it instead of. So libvirt shutdown will show libvirtd, kill from bash shows bash, ...) * B) >=Xenial - B1 - prepare a hotplug xml and a SR-IOV device - that depends on your system, one example is outlined here: # Prep VFs and attach $ echo 4 | sudo tee /sys/bus/pci/devices/0005\:01\:00.0/sriov_numvfs $ sudo modprobe vfio-pci $ lspci -n -s 0005:01:01.3 0005:01:01.3 0200: 10df:e228 (rev 10) $ cat VF-5.1.1.3.xml - B2 until bug 1679704 is fixed you need to manually increase the locked memory limit of the qemu process before going on - B3 attach the device $ virsh attach-device z-test VF-5.1.1.3.xml - B-check: without the fix it will fail for a set of apparmor denials with the fix the attaching will succeed * C) >=Zesty - C1 - on a ppc64el system start and stop a guest - C-check: without the fix apparmor will hold many denies for ppc64_cpu and/or accessing /sys/devices/system/cpu/... With the fix not only the denies are gone, but also if you run on a system with SMT enabled (kvm will fail there) it will report to you in the log about "Error: You must disable SMT ..." [Regression Potential] * We are only further "opening up" the current apparmor profiles. So we should not end up affecting existing use cases by new blocks. * There is a very slight chance that due to accesses being allowed follow on actions are triggered which people are not used to like "the VF hot attach actually working". So if one relied on it not working it will be different for them. * Further I made some brainstorming on the potential effects but the only other one that came to my mind being a regression of some sort is that it now correctly states what send the shutdown signal. So when qemu did not end by itself (guest stops) but is stopped (shutdown) the old message was: terminating on signal 15 from pid 22938 () And now will be like: terminating on signal 15 from pid 7714 (/usr/sbin/libvirtd) For the hopefully super unlikely case that someone e.g. grepped for unknown here it might be a regression.
[Group.of.nepali.translators] [Bug 1680384] Re: libvirt-qemu apparmor profiles misses several important entries
This bug was fixed in the package libvirt - 2.5.0-3ubuntu5.1 --- libvirt (2.5.0-3ubuntu5.1) zesty; urgency=medium * Add missing apparmor profile entries (LP: #1680384) - debian/patches/ubuntu/apparmor-vfio.patch: apparmor: add /dev/vfio for vf (hot) attach - debian/patches/ubuntu/apparmor-ppcwrapper.patch: apparmor: allow extra tools executed by kvm.powerpc - debian/patches/ubuntu/apparmor-shutdown.patch: apparmor: allow to parse cmdline of the pid that send the shutdown signal -- Christian Ehrhardt Wed, 26 Apr 2017 13:47:27 +0200 ** Changed in: libvirt (Ubuntu Zesty) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1680384 Title: libvirt-qemu apparmor profiles misses several important entries Status in libvirt package in Ubuntu: Fix Released Status in libvirt source package in Trusty: Incomplete Status in libvirt source package in Xenial: Fix Committed Status in libvirt source package in Yakkety: Fix Released Status in libvirt source package in Zesty: Fix Released Bug description: [Impact] * Attaching of virtual functions (SR-IOV) not possible without manually modification of apparmor rules * libvirt/qemu guest logfiles can not state the program that sent the shutdown signal * on ppc64el when starting on SMT enabled it failes (expected) but does not present the hint about SMT being the reasons that was added in >=zesty * various apparmor denials in the log hide other issues * Fix by opening up apparmor rules as needed for these use-cases [Test Case] * The rules covere a set of use cases, outlining them all here. Some only apply to >=Zesty, so I mark each subtest with release names. * All start with "Spawn a kvm guest e.g. via uvtool-libvirt" * A) >=Xenial - shutdown message - A1 - start the guest - A2 - stop the guest - A3 - check the log in /var/log/libvirt/qemu/.log - A-check: without the fix the log ends with With the fix it shall contain the name of the process stopping it instead of. So libvirt shutdown will show libvirtd, kill from bash shows bash, ...) * B) >=Xenial - B1 - prepare a hotplug xml and a SR-IOV device - that depends on your system, one example is outlined here: # Prep VFs and attach $ echo 4 | sudo tee /sys/bus/pci/devices/0005\:01\:00.0/sriov_numvfs $ sudo modprobe vfio-pci $ lspci -n -s 0005:01:01.3 0005:01:01.3 0200: 10df:e228 (rev 10) $ cat VF-5.1.1.3.xml - B2 until bug 1679704 is fixed you need to manually increase the locked memory limit of the qemu process before going on - B3 attach the device $ virsh attach-device z-test VF-5.1.1.3.xml - B-check: without the fix it will fail for a set of apparmor denials with the fix the attaching will succeed * C) >=Zesty - C1 - on a ppc64el system start and stop a guest - C-check: without the fix apparmor will hold many denies for ppc64_cpu and/or accessing /sys/devices/system/cpu/... With the fix not only the denies are gone, but also if you run on a system with SMT enabled (kvm will fail there) it will report to you in the log about "Error: You must disable SMT ..." [Regression Potential] * We are only further "opening up" the current apparmor profiles. So we should not end up affecting existing use cases by new blocks. * There is a very slight chance that due to accesses being allowed follow on actions are triggered which people are not used to like "the VF hot attach actually working". So if one relied on it not working it will be different for them. * Further I made some brainstorming on the potential effects but the only other one that came to my mind being a regression of some sort is that it now correctly states what send the shutdown signal. So when qemu did not end by itself (guest stops) but is stopped (shutdown) the old message was: terminating on signal 15 from pid 22938 () And now will be like: terminating on signal 15 from pid 7714 (/usr/sbin/libvirtd) For the hopefully super unlikely case that someone e.g. grepped for unknown here it might be a regression. And making that message more useful (along with getting rid of the associated aa deny is part of the intended fix). [Other Info] * Tested manually and via regression tests in advance on bileto tickets. So all are green there now, there were two unrelated in some dep8 tests due to what seems transient network timeout
[Group.of.nepali.translators] [Bug 1680384] Re: libvirt-qemu apparmor profiles misses several important entries
This bug was fixed in the package libvirt - 2.1.0-1ubuntu9.5 --- libvirt (2.1.0-1ubuntu9.5) yakkety; urgency=medium * Add missing apparmor profile entries (LP: #1680384) - debian/patches/ubuntu/apparmor-vfio.patch: apparmor: add /dev/vfio for vf (hot) attach - debian/patches/ubuntu/apparmor-shutdown.patch: apparmor: allow to parse cmdline of the pid that send the shutdown signal -- Christian Ehrhardt Wed, 26 Apr 2017 13:46:42 +0200 ** Changed in: libvirt (Ubuntu Yakkety) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1680384 Title: libvirt-qemu apparmor profiles misses several important entries Status in libvirt package in Ubuntu: Fix Released Status in libvirt source package in Trusty: Incomplete Status in libvirt source package in Xenial: Fix Committed Status in libvirt source package in Yakkety: Fix Released Status in libvirt source package in Zesty: Fix Committed Bug description: [Impact] * Attaching of virtual functions (SR-IOV) not possible without manually modification of apparmor rules * libvirt/qemu guest logfiles can not state the program that sent the shutdown signal * on ppc64el when starting on SMT enabled it failes (expected) but does not present the hint about SMT being the reasons that was added in >=zesty * various apparmor denials in the log hide other issues * Fix by opening up apparmor rules as needed for these use-cases [Test Case] * The rules covere a set of use cases, outlining them all here. Some only apply to >=Zesty, so I mark each subtest with release names. * All start with "Spawn a kvm guest e.g. via uvtool-libvirt" * A) >=Xenial - shutdown message - A1 - start the guest - A2 - stop the guest - A3 - check the log in /var/log/libvirt/qemu/.log - A-check: without the fix the log ends with With the fix it shall contain the name of the process stopping it instead of. So libvirt shutdown will show libvirtd, kill from bash shows bash, ...) * B) >=Xenial - B1 - prepare a hotplug xml and a SR-IOV device - that depends on your system, one example is outlined here: # Prep VFs and attach $ echo 4 | sudo tee /sys/bus/pci/devices/0005\:01\:00.0/sriov_numvfs $ sudo modprobe vfio-pci $ lspci -n -s 0005:01:01.3 0005:01:01.3 0200: 10df:e228 (rev 10) $ cat VF-5.1.1.3.xml - B2 until bug 1679704 is fixed you need to manually increase the locked memory limit of the qemu process before going on - B3 attach the device $ virsh attach-device z-test VF-5.1.1.3.xml - B-check: without the fix it will fail for a set of apparmor denials with the fix the attaching will succeed * C) >=Zesty - C1 - on a ppc64el system start and stop a guest - C-check: without the fix apparmor will hold many denies for ppc64_cpu and/or accessing /sys/devices/system/cpu/... With the fix not only the denies are gone, but also if you run on a system with SMT enabled (kvm will fail there) it will report to you in the log about "Error: You must disable SMT ..." [Regression Potential] * We are only further "opening up" the current apparmor profiles. So we should not end up affecting existing use cases by new blocks. * There is a very slight chance that due to accesses being allowed follow on actions are triggered which people are not used to like "the VF hot attach actually working". So if one relied on it not working it will be different for them. * Further I made some brainstorming on the potential effects but the only other one that came to my mind being a regression of some sort is that it now correctly states what send the shutdown signal. So when qemu did not end by itself (guest stops) but is stopped (shutdown) the old message was: terminating on signal 15 from pid 22938 () And now will be like: terminating on signal 15 from pid 7714 (/usr/sbin/libvirtd) For the hopefully super unlikely case that someone e.g. grepped for unknown here it might be a regression. And making that message more useful (along with getting rid of the associated aa deny is part of the intended fix). [Other Info] * Tested manually and via regression tests in advance on bileto tickets. So all are green there now, there were two unrelated in some dep8 tests due to what seems transient network timeouts (worked on retry) - if showing up in proposed as well we will likely have to retrigger the tes
[Group.of.nepali.translators] [Bug 1680384] Re: libvirt-qemu apparmor profiles misses several important entries
- Added and filled associated SRU Template - checked once more the dep8 tests on the test bileto ppa - checked regression tests - added tasks for affected releases With that in place uploaded to the unapproved queue of these releases Please do note that Trusty is a bit old for the SRU as-is, I'll need to revaluate it once the others passed. Reasoning: a) no complains so far about that release b) I'll need to re-use my test system and heavily modify it as it usually isn't working on trusty. c) not stalling the fixes for those we can verify more easily ** Changed in: libvirt (Ubuntu Xenial) Status: Triaged => In Progress ** Changed in: libvirt (Ubuntu Yakkety) Status: Triaged => Fix Committed ** Changed in: libvirt (Ubuntu Xenial) Status: In Progress => Fix Committed ** Changed in: libvirt (Ubuntu Zesty) Status: Triaged => Fix Committed ** Also affects: libvirt (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: libvirt (Ubuntu Trusty) Status: New => Incomplete -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1680384 Title: libvirt-qemu apparmor profiles misses several important entries Status in libvirt package in Ubuntu: Fix Released Status in libvirt source package in Trusty: Incomplete Status in libvirt source package in Xenial: Fix Committed Status in libvirt source package in Yakkety: Fix Committed Status in libvirt source package in Zesty: Fix Committed Bug description: [Impact] * Attaching of virtual functions (SR-IOV) not possible without manually modification of apparmor rules * libvirt/qemu guest logfiles can not state the program that sent the shutdown signal * on ppc64el when starting on SMT enabled it failes (expected) but does not present the hint about SMT being the reasons that was added in >=zesty * various apparmor denials in the log hide other issues * Fix by opening up apparmor rules as needed for these use-cases [Test Case] * The rules covere a set of use cases, outlining them all here. Some only apply to >=Zesty, so I mark each subtest with release names. * All start with "Spawn a kvm guest e.g. via uvtool-libvirt" * A) >=Xenial - shutdown message - A1 - start the guest - A2 - stop the guest - A3 - check the log in /var/log/libvirt/qemu/.log - A-check: without the fix the log ends with With the fix it shall contain the name of the process stopping it instead of. So libvirt shutdown will show libvirtd, kill from bash shows bash, ...) * B) >=Xenial - B1 - prepare a hotplug xml and a SR-IOV device - that depends on your system, one example is outlined here: # Prep VFs and attach $ echo 4 | sudo tee /sys/bus/pci/devices/0005\:01\:00.0/sriov_numvfs $ sudo modprobe vfio-pci $ lspci -n -s 0005:01:01.3 0005:01:01.3 0200: 10df:e228 (rev 10) $ cat VF-5.1.1.3.xml - B2 until bug 1679704 is fixed you need to manually increase the locked memory limit of the qemu process before going on - B3 attach the device $ virsh attach-device z-test VF-5.1.1.3.xml - B-check: without the fix it will fail for a set of apparmor denials with the fix the attaching will succeed * C) >=Zesty - C1 - on a ppc64el system start and stop a guest - C-check: without the fix apparmor will hold many denies for ppc64_cpu and/or accessing /sys/devices/system/cpu/... With the fix not only the denies are gone, but also if you run on a system with SMT enabled (kvm will fail there) it will report to you in the log about "Error: You must disable SMT ..." [Regression Potential] * We are only further "opening up" the current apparmor profiles. So we should not end up affecting existing use cases by new blocks. * There is a very slight chance that due to accesses being allowed follow on actions are triggered which people are not used to like "the VF hot attach actually working". So if one relied on it not working it will be different for them. * Further I made some brainstorming on the potential effects but the only other one that came to my mind being a regression of some sort is that it now correctly states what send the shutdown signal. So when qemu did not end by itself (guest stops) but is stopped (shutdown) the old message was: terminating on signal 15 from pid 22938 () And now will be like: terminating on signal 15 from pid 7714 (/usr/sbin/libvirtd) For the hopefully super unlikely case that someo
