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 _______________________________________________ virt mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/virt
