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: Tue, 15 Sep 2015 08:03:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eduardo Habkost <address@hidden> writes:

> On Mon, Sep 14, 2015 at 09:09:12AM -0600, Eric Blake wrote:
>> On 09/13/2015 03:28 AM, Michael S. Tsirkin wrote:
>> > 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.
>> 
>> New qemu with old libvirt isn't always guaranteed to work. And new
>> libvirt can be patched to automatically update any old hard-coded
>> machine name to a newer safe alternative, _when such update is proven
>> safe_ (we've done it in the past for Fedora: if I recall correctly,
>> Fedora 13 branched its own machine type, then in Fedora 15 qemu decided
>> to quit supporting the branch, so libvirt was patched downstream in
>> Fedora 15-17 to rewrite the old name into its safe upstream counterpart.
>>  The downstream patch was dropped in Fedora 18 since F15 was EOL by then
>> so no more new machines would have been created with the old spelling,
>> and since a year was deemed long enough for people to have either run
>> their guest to pick up the automatic update, or that their guest was so
>> infrequently run that they could read the error message and act on it
>> themselves).
>> 
>> Failing to start guests isn't nice, but it also isn't the end of the
>> world, when there is no choice but to break ABI.  An explicit ABI break
>> (by making the user rewrite machine type) is better than silent change
>> in behavior with a potential for broken guests.
>
> What I get from this, is that this is an user interface and usability
> problem, and it's better to solve it at the appropriate layer (which is
> not QEMU).
>
> If QEMU can't emulate those machines anymore, QEMU's job is to just tell
> that to libvirt (so libvirt and management layers can decide what's the
> best way to help the user cope with it), instead of lying to them and
> say that we still emulate the same machine when we actually don't.

Seconded.

The story for direct use by humans is at least as convincing.



reply via email to

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