qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v2 00/16] visitor+BER migration format


From: Markus Armbruster
Subject: Re: [Qemu-devel] [RFC PATCH v2 00/16] visitor+BER migration format
Date: Wed, 07 May 2014 07:49:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

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

> On Tue, May 06, 2014 at 07:58:07PM +0100, Dr. David Alan Gilbert wrote:
>> * Markus Armbruster (address@hidden) wrote:
>> > "Michael S. Tsirkin" <address@hidden> writes:
>> 
>> <snip>
>> 
>> > > OK but for a new machine type, let's default to BER, right?
>> > > I see no reason to keep supporting when non-BER when -M specifies 2.1
>> > > compatibility, do you?
>> > 
>> > I fail to see the relation between machine type and migration's wire
>> > encoding.
>> 
>> New machine types are a useful but not definitive line in the sand.  If
>> you enable something/change the default on a new machine type you know
>> it won't break any existing users since there aren't any.
>> 
>> Dve

The purpose of machine types is to keep the guest ABI stable.  I don't
like tacking random crap unrelated to guest ABI to machine types.
They're hard enough to grasp for users as they are.

> Exactly. And on the other hand, someone enabling old machine type
> and doing live migration is likely to want to be compatible with old
> qemu wrt migration.

Machine types let you migrate to a newer QEMU (forward migration)
without messing up the guest ABI.  Migrating to an older QEMU (backward
migration) basically doesn't work, and as long as that's the case,
picking the older wire format by default is worthless.



reply via email to

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