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: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH] q35: Remove old machine versions
Date: Mon, 14 Sep 2015 16:43:13 -0300
User-agent: Mutt/1.5.23 (2014-03-12)

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.

-- 
Eduardo



reply via email to

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