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