[Users] [libvirt] Migration issues with ovirt 3.3

[Jiri Denemark]

On Fri, Oct 11, 2013 at 22:41:32 +0100, Dan Kenigsberg wrote:
> On Thu, Oct 10, 2013 at 08:40:29AM +0200, Jiri Denemark wrote:
> > On Wed, Oct 09, 2013 at 16:18:25 +0100, Dan Kenigsberg wrote:
> > > On Wed, Oct 09, 2013 at 04:52:20PM +0200, Gianluca Cecchi wrote:
> > > > On Wed, Oct 9, 2013 at 3:43 PM, Dan Kenigsberg  wrote:
> > > > > On Wed, Oct 09, 2013 at 02:42:22PM +0200, Gianluca Cecchi wrote:
> > > > >> On Tue, Oct 8, 2013 at 10:40 AM, Dan Kenigsberg wrote:
> > > > >>
> > > > >> >
> > > > >> >>
> > > > >> >> But migration still fails
> > > > >> >>
> > > > >> >
> > > > >> > It seems like an unrelated failure. I do not know what's blocking
> > > > >> > migration traffic. Could you see if libvirtd.log and qemu logs at source
> > > > >> > and destinaiton have clues?
> > > > >> >
> > > > >>
> > > > >> It seems that on VM.log under qemu of desdt host I have:
> > > > >> ...
> > > > >> -incoming tcp:[::]:49153: Failed to bind socket: Address already in use
> > > > >
> > > > > Is that port really taken (`ss -ntp` should tell by whom)?
> > > > 
> > > > yeah !
> > > > It seems gluster uses it on both sides
> > > 
> > > Since libvirt has been using this port range first, would you open a
> > > bug on gluster to avoid it?
> > > 
> > > Dan. (prays that Vdsm is not expected to edit libvirt's migration port
> > > range on installation)
> > 
> > If it makes you feel better, you can't even do that :-) Unfortunately,
> > the port range used for migration is hard-coded in libvirt. And since we
> > don't use port allocator yet (patches are in progress), we don't
> > automatically avoid ports that are already taken. All this is going to
> > change, though.
> 
> Are these patches posted? Is there a libvirt BZ that tracks this issue?

https://www.redhat.com/archives/libvir-list/2013-October/msg00513.html
is v3 of a patch that makes libvirt skip ports that are already in use.
Of course, if something binds to that port just before QEMU is started,
it will still fail. But that's a separate issue that may only be solved
by giving QEMU a socket which is already bound rather than telling QEMU
to bind to it.

A patch for making the port range configurable was not post yet...

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1018530

Jirka