11:44 a.m.
On 12/13/2011 10:15 AM, Amit Shah wrote:
>> The fedora-13 machine type was just a slightly modified
pc-0.12
>> machine type, so using pc-0.12 should be the safest.
>
> That's wrong. The whole reason fedora-13 was introduced was because it
> exposed MORE features than stock pc-0.12, so it is closer either to
> pc-0.13 or to pc-0.14.
I wonder how you say that. It's closer to pc-0.12 since there was
exactly one feature additional in fedora-13 since pc-0.12.
Maybe in F13 and F14 that was the case, but we're talking about F15 and
F16. In those builds, qemu ALREADY modified (gasp!) the 'fedora-13'
machine name to be an alias for 'pc-0.14', not 'pc-0.12' or
'pc-0.13'.
If Windows required reactivation when upgrading from F14 to F15, no one
has mentioned it. But the point remains that _any_ VM state saved of a
running guest, while using F15 or F16 as the host and using 'fedora-13'
as the guest machine type, whether by migration (including migration to
file in 'virsh save' and 'virsh managedsave' or migration across hosts
in 'virsh migrate') or by snapshots (via the savevm monitor command in
'virsh snapshot-create'), contains subsections which qemu refuses to
parse if the destination qemu is running 'pc-0.12' or 'pc-0.13', but
which work just fine if the destination qemu is running 'pc-0.14'.
The
features added in pc-0.13 and pc-0.14 are not assessed for their
impact in all the cases.
Yes, and that is the unfortunate baggage of creating 'fedora-13' which
we are trying to undo, rather than carry it around forever.
The fact that we saw kvmclock-related
changes break things should be a red flag.
Yes, it IS a red flag - it means that between F14 and F15, when we added
the 'fedora-13' machine hack into F15 qemu, we did it wrong, and made
'fedora-13' an alias for 'pc-0.14' where used to be an alias closer to
'pc-0.12' or 'pc-0.13'. But the damage is already done, and no one has
complained about it. Rather, what they are complaining about is that
any saved machine state is getting lost if qemu is not started with a
machine type that can understand the saved state file; silently
converting 'fedora-13' to 'pc-0.13' creates this situation, which is bad
for the end user, while silently converting 'fedora-13' to 'pc-0.14'
allows the end user to still load their VM state, even if we drop the
'fedora-13' hack from qemu.
For the test that failed,
loading from a saved image, did you try using pc-0.12 and see if that
breaks anything? If it doesn't, won't you say it's better to use
pc-0.12?
On your suggestion, I repeated my testing. Both 'pc-0.12' and 'pc-0.13'
fail miserably; 'virsh restore' (which maps to qemu -incoming migration)
complains about kvmclock, and 'virsh snapshot-revert' (which maps to
loadvm) booted fresh rather than restoring machine state.
> I already proved that we can't do migration from
> fedora-13 to pc-0.13, but can do migration to pc-0.14, which means that,
> at least in F16, fedora-13 is a synonym to pc-0.14, not pc-0.12.
These really are things that we can't exhaustively test. Eg., do
Windows guests complain of device changes? Do they need
re-activation?
We've already lost that battle. Anyone who upgraded from F14 to F15 has
already forced their guest to see new machine characteristics, because
'fedora-13' accidentally changed meaning from 'pc-0.13' to
'pc-0.14'.
At this point, the best we can do is prevent further problems by
converting to 'pc-0.14', which won't cause any reactivation for a guest
whose state was saved by F16, and probably won't cause any reactivation
for a guest whose state was saved by F14 (although we don't know that,
we do know that no one complained about reactivation being required when
they upgraded from F14 to F15).
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org