Re: Does libvirt live migration have error handling on port bind failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17.08.2016 11:02, Prasanna Kalever wrote:
> [ oops! apologies, my previous draft miss the links ]
> 
> Hello,
> 
> This was the scenario close to 3 years back, libvirt's live migration
> tries to use ports in ephemeral port range, but has no fallback to use
> (an)other port(s) when the one it wants is already in use.
> 
> If some port say 49152 is already used by some application say gluster
> in our case (gluster as of today also uses 49152-65535), live
> migration fails because of lack of fallback mechanism in libvirt,
> that's where gluster had compromised to go with some hack [1] on bug
> [2] since getting that addressed in libvirt takes more time than it
> does with gluster.

I'd say we are pretty quick when it comes to bugfixes but maybe that's
just my POV.

> 
> As may releases passed from then in libvirt, I hope now there exist a
> fallback mechanism for port conflicts in libvirt.

Firstly, you can configure whatever port range you want in
/etc/libvirt/qemu.conf:

#migration_port_min = 49152
#migration_port_max = 49215

Secondly, since 9c9d4d32 (merged Jan 16 2013) libvirt uses this port
allocator. It is an internal module that tries to allocate next free
port within configured range. So the whole migration then works like this:

1) source client (or daemon in case of p2p migration) contacts remote
daemon telling it about intended domain migration
2) destination daemon uses port allocator module to find a free port
within configure range
3) destination daemon sends back to the source port number (or an error
if none was found)
4) source proceeds with the received port number

> 
> Can someone confirm so ?
> 
> Also It will be greatly appreciable, if someone can tell how the port
> binding (mostly defense on clash) works with libvirt live migration
> today ?
> 

There is none. I mean, there will always be a window between "detecting
port free" and "starting qemu which binds to it".
One thing that we could do is to bind to the port immediately (thus
holding it open without receiving anything on it) and passing it to qemu
as it starts. However, who would unbind the port if the source decides
not to migrate after step 4) from my example above?

Michal

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]