[libvirt] Silently ignored virDomainRestore failures

Charles Duffy charles at dyfis.net
Tue Sep 29 11:08:04 UTC 2009


On Tue, Sep 29, 2009 at 4:16 AM, Daniel P. Berrange <berrange at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20090929/0f530efb/attachment-0001.htm>


More information about the libvir-list mailing list