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: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | 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 16:50:15 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Benjamin LaHaise
2010-09-13 19:06:18 UTC
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. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. 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. Doesn't this boil down to a request to persist the state of the VM and attempt to recreate it on libvirt start? 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. 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. |