Description of problem: Because of bug 901631 libvirt is unable to suspend certain VMs. However libvirt-guests.sh does not check whether suspending fails and does not report that suspending failed. Therefore guests might be hard-resetted if the host is rebooted. Version-Release number of selected component (if applicable): libvirt-client-1.2.8-16.el7_1.3 How reproducible: always Steps to Reproduce: 1. Create a VM that cannot suspend (e.g. because of using a SATA instead of a VirtIO disk) 2. power off VM host Actual results: - VM is hard powered-off - No errors are reported Expected results: - VM should be gracefully powered-off - Error about virsh managedsave should be reported Additional info: This seems to be a bug in Fedora 22 as well.
I can reproduce this: libvirt-client-1.2.17-13.el7_2.2.x86_64 1.Prepare a guest with sata controller: ... <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </controller> ... 2. Start libvirt-guests service: # systemctl start libvirt-guests 3. start the guest(named rhel7.2) 4. Reboot host 5. After host boots, guest is started again 6. Check guest log: # cat /var/log/libvirt/qemu/rhel7.2.log ... qemu: terminating on signal 15 from pid 1 2016-01-19 06:26:42.288+0000: shutting down ... From the qemu log, we can see the guest is killed by signal 15 from pid 1(systemd) when host shuts down
There is nothing we can do about this issue with libvirt-guests.sh. The plan is to start using systemd units for vm start/shutdown.
(In reply to Jaroslav Suchanek from comment #2) > There is nothing we can do about this issue with libvirt-guests.sh. The plan > is to start using systemd units for vm start/shutdown. This does not really address the problem. Also with systemd units there needs to be code to handle a failed suspend and to do a proper shutdown instead. Is this behavior mentioned in the requirements for a systemd based solution?