[libvirt] Does libvirt live migration have error handling on port bind failure

[Michal Privoznik]

On 23.08.2016 08:57, Prasanna Kalever wrote:
> On Tue, Aug 23, 2016 at 4:10 AM, Michal Privoznik <mprivozn at redhat.com> wrote:
>> On 17.08.2016 11:02, Prasanna Kalever wrote:
>>> [ oops! apologies, my previous draft miss the links ]
>>>
>>> Hello,
>>>

> Thanks Michal that really helps.
> 
> So If I understand it right, in the window between destination daemon
> passing the port (listening) and source (qemu) binding to it, there
> could be some other external process that uses the same port (race?
> again I'm not sure how big the window is?)

Yes. there's this possibility. But then again - these applications
you're using should be configured to use different sets of ports. For
instance libvirt can use 49152 - 49182, while gluster could use 49183 -
49213.

The window is not that long. Maybe my description in the previous e-mail
wasn't that clear. At the destination, where the port allocation takes
place:
1) libvirt uses its internal module to find a free port
2) libvirt spawns the qemu and tell it to bind to that port
3) libvirt reports back to the migration source host with the port number.

So the window is not that big - probably just a couple of milisecs as
it's just that part between steps 1 and 2. But there always be some
window - even if we implemented what I suggested earlier. That's one of
the limitations of kernel API. One simply doesn't detect port free and
bind to it atomically.

> 
> Don't you think libvirt needs a fall back mechanism here, since the
> port numbers could be in ephemeral port range and are free to be used
> by any application ?

You should fix the application then. Or its configuration. We may end up
in fallback loop if two applications with the fallback start fighting
over the ports.

I mean, if it was libvirt who allocates the migration port(socket) for
qemu and then just merely pass the FD to it, then libvirt could do a
couple of tries to allocate the port (bind socket to it). However, if it
is still qemu doing that, we would need to spawn qemu each time we want
to try next port. That's not very efficient.

Frankly, I have no idea why we don't allocate the port ourselves. I'll
ask offline our migration guru and let you know :)

Michal