On Tue, Sep 29, 2009 at 4:16 AM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:
Yeah, I've been thinking much the same this morning. I think we shouldconsider what the optimal setup is for our needs long term and try and
do whatever we can for that in QEMU now. I think it'd definitely be
worthwhile to have an 'info migrate' impl for incoming migration, and
even to make '-incoming' optional, and add a 'migrate-incoming' command
to the monitor, which like 'migrate' could be run in either blocking
or non-blocking mode.
'migrate-incoming' is heavier surgery than I'm comfortable doing myself, but I'll try my hand at the info command.
The only thing that bugs me about this is that if the output is being added to the existing 'info migrate', an explicit negative output ("Incoming: none") will be necessary to distinguish from the case where reporting incoming migration is simply unsupported; as such, the current behavior of reporting no output at all if no migration is ongoing would need to change.
For existing QEMU, it might be sufficient to just put an arbitrary
'sleep(5)' before issuing 'cont', which would at least give it a
reasonable chance of avoiding the race condition.
Well -- I wasn't going to submit the patch I'm now using internally (using and waiting for a sigil on stderr when migrate_url is "stdin"), but I suppose that with an else clause doing a sleep it might actually be the closest available option to a Right Thing for preexisting qemu.
I'll wait to hear back today from the contractors testing with it (they were hitting this race condition frequently) and post an amended copy here if it gets their thumbs-up.
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list