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