On Tue, Sep 29, 2009 at 4:16 AM, Daniel P. Berrange <berrange(a)redhat.com>wrote:
Yeah, I've been thinking much the same this morning. I think we
should
consider 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.