[fedora-virt] [fedora-specific libvirt PATCH] qemu: replace deprecated fedora-13 machine type with pc-0.13

[Justin M. Forbes]

On Tue, 2011-12-13 at 10:44 -0700, Eric Blake wrote:
> 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).
> 
Indeed, and this is my fault for not following up on the patch which was
a quick hack once F14 came out.  I should have followed up, but in the
meantime, anyone who has used F15 with that patch is already running the
guest as a pc-0.14 machine type.  Now that the patch is in F16, this
applies there as well.  Strangely no one seems to complain at all in
this case, but we do get complaints when the guest will not start
because fedora-13 is not a supported machine type.  Judging from how
quickly we saw these after F16 launch, I would be willing to bet that
most of these cases were running F15 as well, so have been operating as
a pc-0.14 guest for some time.

Justin