qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections


From: Juan Quintela
Subject: Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections
Date: Wed, 15 Oct 2014 17:59:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Eric Blake <address@hidden> wrote:
> On 10/15/2014 01:55 AM, Juan Quintela wrote:
>> Hi
>> 
>> by popular demand, and after too many time, this series.  This is an
>> RFC to know what people think about how to use them, the interface
>> proposed, whatever.
>> 
>> * simplify optional subsections moving the "needed" function to
>>   vmstate description.  I think that this simplification makes sense
>>   by itself, it is indipendent of the rest of the patches.
>> 
>> * runstate: To make an example of an optional section, I decided to
>>   use current runstate.  Right now, we have a problem when:
>>   - we start destination without -S
>>   - we run migration, and it causes an ioerror on source, but migration 
>> finishes
>>   - we try to run migration on destination anyways, when it is
>>     possible that we could get disk corruption (the ioerror was there for a 
>> reason)
>>   Luiz: You can see any obvious improvement about how we use runstates?
>>   Laine: Could you told me if you (libvirt) like this or would want
>>      something a bit different?
>
> Right now, libvirt always uses -S, then just calls 'cont' on the
> destination to resume the CPUs (if the migration was live and the source
> was in the running state).  But if we start passing other states, 'cont'
> might not be the right thing to do.  For example, if the guest is at S3
> on the source, how do we transfer from in migration to S3 at the
> destination?

It should be transparent (I haven't tested, this series was to ask for
comments before investing more time on it).

> Do we need a new monitor command that says to put the
> guest into the same state that migration said it should be in (and the
> command fails if migration was from an older source that did not send
> the subsection)?

I think that you don't need the command.
Target is started "paused" (-S) or "running" (nothing).


source old: target old: no changes
source old: target new: the same as now, no changes
source new: target new: we set the right state.  And if it is not
"running" we don't run on destination, independent of what is happening.
source new: target old: if source is in state "running" or "paused", no
                        change.  If source is in error state, we sent
                        the section and migration gets aborted (target
                        don't understand it)

source new: target new, running with old machine type:
if state is "running" or "paused", nothing is sent.
if state is "error", target is set to "error".

So, I think that we get all the cases possible right, no?


> How can libvirt introspect that the destination qemu is new enough to
> understand the subsections, and/or that the source qemu is new enough to
> send the subsections?

A new qemu_option value would make for you?

>> 
>> * I sent that option indpendently for new machine types.
>> 
>> * For old machine types I use this as one example of optional section.
>>   We only sent it when the state is different from "running" or "paused".
>> 
>>   So, the only case where we fail is if we migrate to an old qemu and
>>   there is one error.
>
> Seems reasonable.
>
>> 
>> * On the runstate subsection "postload" we can send any event for
>>   anything that libvirt wants when migration finishes.
>>   Laine, can you told us what libvirt would preffer for this?
>
> So you're thinking that an event on the destination emitted stating that
> 'incoming migration is complete, and requests the following state' is
> sufficient for libvirt to know how to put the domain into that state?

It is up to libvirt what to do.

My idea here is that, if you don't use libvirt, you just start without
-S.

If you use libvirt, and you *don't* need to do anything special to run
after migration, you shouldn't use -S.  And I would emit an event saying
"migration was finished".

But what I want to know is _what_ events are you interested in?

Later, Juan.



reply via email to

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