qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/3] migration: Add x-validate-uuid capability


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 1/3] migration: Add x-validate-uuid capability
Date: Tue, 27 Aug 2019 11:18:03 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 8/27/19 10:36 AM, Yury Kotov wrote:
> 27.08.2019, 17:02, "Eric Blake" <address@hidden>:
>> On 8/27/19 7:02 AM, Yury Kotov wrote:
>>>  This capability realizes simple source validation by UUID.
>>>  It's useful for live migration between hosts.
>>>

>>
>> Any reason why this is marked experimental? It seems useful enough that
>> we could probably just add it as a fully-supported feature (dropping the
>> x- prefix) - but I'll leave that up to the migration maintainers.
>>
> 
> I thought that all new capabilities have x- prefix... May be it's really
> unnecessary here, I'm not sure.

New features that need some testing or possible changes to behavior need
x- to mark them as experimental, so we can make those changes without
worrying about breaking back-compat.  But new features that are outright
useful and presumably in their final form, with no further
experimentation needed, can skip going through an x- phase.

> 
>> In fact, do we even need this to be a tunable feature? Why not just
>> always enable it? As long as the UUID is sent in a way that new->old
>> doesn't break the old qemu from receiving the migration stream, and that
>> old->new copes with UUID being absent, then new->new will always benefit
>> from the additional safety check.
>>
> 
> In such case we couldn't migrate from e.g. 4.2 to 3.1

I don't know the migration format enough to know if there is a way for
4.2 to unconditionally send a UUID as a subsection such that a receiving
3.1 will ignore the unknown subsection. If so, then you don't need a
knob; if not, then you need something to say whether sending the
subsection is safe (perhaps default on in new machine types, but default
off for machine types that might still be migrated back to 3.1).  That's
where I'm hoping the migration experts will chime in.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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