Description: Errors on console from sourcing disk.cfg; rc.local_shutdown timeout should be 90 seconds not 60.

 

How to reproduce: Shutdown normally.

 

Expected results: No console errors from sourcing disk.cfg.

 

Actual results: Lots of console errors.

 

Other information: The default shutdown timeout in rc.local_shutdown should be 90 seconds.

Yes saw this too, those console messages are harmless but we'll get rid of them.

 

You want a 90 sec default shutdown timeout?  ok.  We'll leave the default vm shutdown timer at 60.  Both need to be less than the UPS "Runtime left to initiate shutdown", or if using UPS "Time on battery before shutdown" these timeouts need to be considered.

 

'shutdown' is an interesting problem, mainly due to windows VM's because those things can take a long time to shutdown if there are updates happening, yet, if we are shutting down because we lost power and are running on battery, we can't let windows take too long...

As mentioned in another topic, if the Windows VMs have hibernate enabled, and are stopped with virsh dompmsuspend <domain> disk, then the resident Qemu guest agent will hibernate the machine, which should also bypass any Windows Updates pending.

As mentioned in another topic, if the Windows VMs have hibernate enabled, and are stopped with virsh dompmsuspend <domain> disk, then the resident Qemu guest agent will hibernate the machine, which should also bypass any Windows Updates pending.

 

Is it supported if doing hardware pass through? As far as I remember, that was the reason it haven't been implemented.

This is different from KVM+Qemu doing "save" on the VM state. This is ordering the guest to perform its own hibernate or suspend to disk. So long as the guest can save and restore the state of its own hardware, and so long as you feed it the same configuration on next boot, it should be perfectly safe. In fact, the XML should even maintain the exact same hardware layout, as long as you don't do anything to regenerate the PCI bus/slot/etc values.

 

E: dom pm suspend -> domain power management suspend state. Basically, tell the guest agent, or through ACPI, to perform its own S3 or S4 suspend. Adding the "disk" target makes it an S4 suspend. The guest takes care of shutting down the passed in hardware, including saving any state it needs using the device drivers.

 

The reason Qemu cannot reliably save its own states with pass through is that it would require full support for every piece of hardware passed through, to know how and where to interrupt the guest connection and save its own state data. Doing S4 suspend with the guest OS takes that out of Qemu's hands. The guest has the full drivers for every device passed through, and as long as those devices supported hibernate on bare metal, they should also work fine in virtualization, assuming every device supports its own soft reset. Weird cases where devices won't even reset to be usable within a reboot cycle of the VM would break if restarted without the host OS being rebooted, of course, but I don't know which devices are this flaky.