qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] migration: Convert 'status' of MigrationInfo


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2] migration: Convert 'status' of MigrationInfo to use an enum type
Date: Fri, 27 Feb 2015 10:42:59 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 02/27/2015 10:07 AM, Dr. David Alan Gilbert wrote:
>>
>> Rather than pollute the user-exposed enum with a state that we will
>> never report, can we come up with some internal-only method for tracking
>> cancelling separate from the enum?
> 
> Well I guess we could just report it; but would that break any external tools?

It might - I seem to recall in the past that when we added a new state
string, that at least libvirt choked when encountering the unknown
string (but I don't recall if it was migration or something else).  At
least libvirt already has an enum tracking:

enum {
    QEMU_MONITOR_MIGRATION_STATUS_INACTIVE,
    QEMU_MONITOR_MIGRATION_STATUS_ACTIVE,
    QEMU_MONITOR_MIGRATION_STATUS_COMPLETED,
    QEMU_MONITOR_MIGRATION_STATUS_ERROR,
    QEMU_MONITOR_MIGRATION_STATUS_CANCELLED,
    QEMU_MONITOR_MIGRATION_STATUS_SETUP,

    QEMU_MONITOR_MIGRATION_STATUS_LAST
};

and a string mapping of just the following states:

VIR_ENUM_IMPL(qemuMonitorMigrationStatus,
              QEMU_MONITOR_MIGRATION_STATUS_LAST,
              "inactive", "active", "completed", "failed", "cancelled",
"setup")

Furthermore, the function qemuMigrationUpdateJobStatus() is doing
various things depending on the observed state, where the current trick
of treating 'cancelling' like 'active' would mean that changing
'cancelling' to be an independent state WOULD have observable behavior
change in libvirt.  But I don't know if the change would break things,
or if it would still end up resolving nicely (after all, cancelling only
occurs for a short window before the migration aborts anyway, so it
might just sort itself out when it finally gets to cancelled).

On the other hand, we can argue that clients that are unprepared to
handle new enum states gracefully are broken, and we also have the
argument that it is okay for a new qemu to require a new libvirt release
(the other direction is not okay - a new libvirt must not require
upgrading to a new qemu).  So exposing 'cancelling' may make this patch
easier.

-- 
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]