[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
signature.asc
Description: OpenPGP digital signature