This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 633443

Summary: libvirt does not restart guests after unclean system shutdown (power loss or hard reset or system crash)
Product: [Fedora] Fedora Reporter: Benjamin LaHaise <bcrl>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: berrange, clalance, crobinso, dallan, eblake, itamar, jforbes, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-01 11:50:15 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Benjamin LaHaise 2010-09-13 15:06:18 EDT
Description of problem:


Version-Release number of selected component (if applicable):

libvirt-0.8.2-1.fc13.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Benjamin LaHaise 2010-09-13 15:09:26 EDT
Description of problem:

Guests do not start after unclean system shutdown.

Version-Release number of selected component (if applicable):

libvirt-0.8.2-1.fc13.x86_64

How reproducible:

Always.

Steps to Reproduce:
1. Start guest
2. cause host to reboot without shutdown (ie hard reset)
3. observe guests not starting on reboot

Actual results:

Guests do not enter power on state after reboot.

Expected results:

Guests should power on after reboot.
Comment 2 Fedora Admin XMLRPC Client 2011-09-22 13:50:04 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 3 Fedora Admin XMLRPC Client 2011-09-22 13:52:58 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 4 Fedora Admin XMLRPC Client 2011-09-22 13:58:23 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Fedora Admin XMLRPC Client 2011-11-30 14:30:51 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 6 Fedora Admin XMLRPC Client 2011-11-30 14:34:30 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 7 Fedora Admin XMLRPC Client 2011-11-30 14:41:06 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Fedora Admin XMLRPC Client 2011-11-30 14:52:04 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 9 Eric Blake 2011-12-01 11:50:15 EST
There's no way to change this fact.  Pulling the power cord is always a risky proposition compared to a proper shutdown.  The best we can do is via the libvirt-guests init script, which will restart guests after a proper shutdown, but that still depends on a shutdown and not a hard reset.

I'm closing this as CANTFIX.
Comment 10 Dave Allan 2011-12-01 17:46:34 EST
Doesn't this boil down to a request to persist the state of the VM and attempt to recreate it on libvirt start?
Comment 11 Eric Blake 2011-12-01 18:00:51 EST
For persistent guests, we already persist the state of the VM - that's how restarting libvirtd knows to reconnect to an existing qemu process.  But across a reboot, the qemu process is gone, so the normal code that libvirtd startup does to reconnect fails, and libvirt just assumes that qemu died for some other reason and transitions the guest back to offline.  How is libvirt supposed to know whether restarting a new qemu process would be appropriate; or put another way, how is libvirt supposed to know that the reason qemu is gone is because of a hard reboot and not for some other reason?  And for transient guests, there's no persistent state saved in the first place.  I'm still not convinced that libvirt can do any better than what the libvirt-guests init script is already doing.
Comment 12 Dave Allan 2011-12-01 19:20:31 EST
I think this could be implemented by setting autostart on domain start and unsetting it on transition to domain shutdown.  In the case in which the power is pulled from the host, the domain will still have autostart set and so will be started on host boot.  In any case, I'm just speculating because I don't have any time to work on this, but I'd support it if somebody contributed the patches upstream.

Benjamin, I think you could get the behavior you want by setting autostart on the VMs you want to start at boot time:

virsh autostart <guest>

You'd just have to remember to set it when you start a guest and unset it if you have a VM that shouldn't autostart.