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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
