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