[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.