Re: [Qemu-devel] [RFC] New thread for the VM migration

[Avi Kivity <avi@redhat.com>]

On 07/14/2011 06:52 PM, Juan Quintela wrote:
> >
> >>  Notice that hotplug/unplug during
> >>  migration don't make a lot of sense anyways.
> >
> >  That's completely wrong.  Hotplug is a guest/end-user operation;
> >  migration is a host/admin operation.  The two don't talk to each other
> >  at all - if the admin (usually a program) wants to migrate at the same
> >  time the user wants to hotplug, which one gets the bad news?  Who will
> >  actually test the combination?
>
> I am not sure if it makes sense, but to be able to allow hotplug during
> migration we need to change lots of things.  It don't work today either,
> so I think it is excesive to fix that on this patch.

Reluctantly agree.  We're adding another obstacle that we have to remove 
later, which I don't really like, but that's life.

> >
> >  You are right.  ram_list _is_ volatile though (but we can't really
> >  change it these days during migration).
>
> I have think a little bit about hotplug&  migration, and haven't arraive
> to a nice solution.
>
> - Disabling hotplug/unplug during migration: easy to do.  But it is not
>    exactly user friendly (we are here).
>
> - Allowing hotplug during migration. Solutions:
>    * allow the transfer of hotplug events over the migration protocol
>      (make it even more complicated, but not too much.  The big problem is
>      if the hotplug succeeds on the source but not the destination, ...)

If we transfer only the guest side of the device (and really, that's the 
only thing we can do), then nothing should ever fail, except for guest 
memory allocation.  If that happens, kill the target.  The source should 
recover.

Maybe we can do this via a magic subsection whose contents are the 
hotplug event.

>    * migrate the device list in stage 3: it fixes the hotplug problem
>      nicely, but it makes the interesting problem that after migrating
>      all the ram, we can find "interesting" problems like: disk not
>      readable, etc.  Not funny.

Yes, that's not very nice.

>    *<insert your nice idea here>
>
> As far as I can see, if we sent the device list 1st, we can create the
> full machine at destination, but hotplug is "interesting" to manage.
> Sending the device list late, solve hotplug, but allows errors after
> migrating all memory (also known as, why don't you told me *sooner*).
>
> No clue about a nice&  good solution.  For now, I think that we should
> go with disabling hotplug/unplug during migration, until we get a better
> idea.

Yes.

-- 
error compiling committee.c: too many arguments to function