qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] migration: Introduce MIGRATION_STATUS_FINISHING


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH] migration: Introduce MIGRATION_STATUS_FINISHING
Date: Tue, 27 Oct 2015 07:11:46 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 10/27/2015 01:08 AM, Pavel Fedin wrote:
>  Hello!
> 
>> adding new user-visible states
>> has a tendency to break existing clients that aren't prepared for
>> unexpected states (although technically such bugs are in the client - in
>> the past, libvirt used to be one such client, although we've tried to
>> fix it to gracefully ignore unknown states).
> 
>  Yes, i know this, my host uses libvirt v1.2.9.3 (i backport necessary 
> patches to it) and it barfed. I didn't check master though...
> 
>>  Are we sure no other
>> existing state works for this?  I'm not opposed to the addition, just
>> wanting to make sure we have good reason for it.
> 
>  You know, actually, this is a thing only for qemu's internal use, we don't 
> need a new state at all. Instead, we could introduce a 'bool cpus_stopped' to 
> MigrationState structure and test for it in migration_in_finishing(), like:
> --- cut ---
> bool migration_in_finishing(MigrationState *s)
> {
>     return s->cpus_stopped;
> }
> --- cut ---
>  What do you think about this solution? It is much less complicated than...

If it is truly internal, then avoiding exposing the state to external
clients is indeed the way to go.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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