Juan Quintela <quintela@xxxxxxxxxx> writes: [...] > 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, ...) > * 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. > * <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*). I figure the errors relevant here happen in device backends (host parts) mostly. Maybe updating just backends is easier than full device hot plug. Configure backends before migrating memory, to catch errors. Reconfigure backends afterwards for hot plug[*]. Then build machine. You still get errors from frontends (device models) after migrating memory, but they should be rare. [...] [*] You could do it "in the middle" to catch errors as early as possible, but I doubt it's worth the trouble. -- 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
