qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] q35: Remove old machine versions


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] q35: Remove old machine versions
Date: Mon, 14 Sep 2015 09:18:47 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

"Michael S. Tsirkin" <address@hidden> writes:

> On Fri, Sep 11, 2015 at 03:44:47PM -0300, Eduardo Habkost wrote:
>> Ping?
>> 
>> So, what's the reason we are still keeping those old machines in the
>> code?
>
> Victor also wanted to clean out some very old machine types for
> the PIIX, too.
>
> But if someone created a machine with libvirt, these machine types
> are now written in the XML. Failing to start guests isn't nice.
>
> Maybe we could drop most of the compat code, but keep the
> old machine types around with most visible changes (no_floppy? anything
> else?). As we can't live migrate these older machine types,
> minor guest visible changes aren't a big deal if they don't
> break guest boot.

We've been through this before, but we can go through it once more.
Choices:

A. Remove old machine type

   A guest using it can't be started.  Easy to understand on the host.
   An error message advising to switch to a newer machine type would be
   a nice touch.

   This is a clean break in backward compatibility.  To be mentioned in
   release notes, obviously.

B. Change old machine type in a guest-visible way

   Depending on the nature of the change and the guest, a guest using it
   either doesn't notice, copes with it successfully, or fails in
   guest-specific ways.  If the latter, the failure can be "guest
   hangs", which is much harder to figure out than A.

   Unless we can *demonstrate* that nothing bad happens for all the
   guests people actually use with the old machine types, this is a
   different kind of backward compatibility break.

   Demonstrating this is feels infeasible to me, but you're welcome to
   try.

I could call the difference between the two a tradeoff, but since we've
been through this before, I'll be more blunt: choosing B robs Peter (the
guy with guests where badness happens) to pay Paul (the guy with guests
that cope).  Paul is saved the inconvenience of having to read release
notes or his logs, and change machine types.  Peter pays for that with
figuring out WTF his guests are doing now.

As a user, I'd pick a clean break in backward compatibility over a hack
that preserves effective compatibility when it works, but breaks it
uncleanly when it doesn't.

As a developer, I'm insisting on it.

So, if you want B, the onus is on *you* to show us why nothing bad will
happen.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]