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
