[fedora-virt] Suspending VMs on host shutdown

[Dor Laor]

On 08/15/2011 06:46 AM, Eric Blake wrote:
> On 08/15/2011 07:38 AM, Dor Laor wrote:
>> On 08/15/2011 05:38 AM, Eric Blake wrote:
>>> On 08/15/2011 04:12 AM, Tom Hughes wrote:
>>>> My specific example was that this morning qemu-kvm updated from
>>>> 0.15.0-1.fc15 to 0.15.0-0.3.201108040af4922.fc15 and shortly after that
>>>> I restarted my host only to find that the VM that had been running for
>>>> some time wouldn't start. Looking at the logs showed:
>>>>
>>>> Unknown savevm section or instance 'kvmclock' 0
>>>> load of migration failed
>>>
>>> That's not good, and it would be nice if we could improve the situation.
>>> However,
>>
>> The above is a bug, there is a mechanism to take care of preserving
>> older version format by specifying a 'machine type' flag using -M
>> qemu0.15. I do think it is there on default so it is just a but in this
>> case.
>>
>> In general, I doubt that savevm is a good thing on host shutdown anyway.
>
> Libvirt isn't using savevm on host shutdown, rather it is using 'migrate
> to file'. As long as qemu is upgraded (not downgraded), and newer qemu
> can do migration from older file, then things are okay. The problem here
> is when newer qemu refuses to migrate from older file; you would have
> the same problem using migration between two machines, one running older
> qemu and the other running a newer one.
>
>> When the guests will be restored, they'll have a time gap and also their
>> tcp connections will probably stop be relevant. It's better to trigger
>> internal guest hibernation (which has some caveats now) or shutdown the
>> guest as you've said).
>
> And how does one go about triggering internal guest hibernation from the
> host libvirt?

You can't do it today but it shouldn't be complex to do it using an 
agent in the guest or through a new monitor command for qemu. There are 
some issues with s3/s4 that we'll fix soon