qemu-devel
[Top][All Lists]
Advanced

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

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] New thread for the VM migration
Date: Thu, 14 Jul 2011 19:07:28 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10

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




reply via email to

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