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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list