On Wed, Oct 9, 2013 at 5:52 PM, Daniel Berteaud wrote:
Le mercredi 09 octobre 2013 à 16:18 +0100, Dan Kenigsberg a écrit :
Since libvirt has been using this port range first, would you open a bug on gluster to avoid it?
Already done: https://bugzilla.redhat.com/show_bug.cgi?id=987555
(not using ovirt, but the problem is easy to trigger as soon as you use GlusterFS and libvirt on the same boxes)
Regards, Daniel
Dan. (prays that Vdsm is not expected to edit libvirt's migration port range on installation)
I added my point to the bugzilla and everyone on oVirt should do so in my opinion... very frustrating.. ;-( And it seems not so easy to change gluster range. I read in past threads for previous versions that the range 24009+ was written inside the code. In 3.4 it should be an option such as --volfile-server-port=PORT from a client point of view... but I tried some things and not able to arrive at a significant point... always 49152 and 49153 used for my two bricks Furthermore, as a side note, I wanted to try migration reattempt it several times as each time it chooses next port. I have two bricks so that the first two attempts fail; in VM.log I get ... -incoming tcp:[::]:49152: Failed to bind socket: Address already in use ... -incoming tcp:[::]:49153: Failed to bind socket: Address already in use Unfortunately, tested three times with same result, after the second attempt the dest node goes into a loop of failing, recoverying from crash, non reposnive. I easily correct the situation with systemctl restart vdsmd on it, but possibly I could have raised some sort of bug. And then if I try again to migrate it restarts from 49152... so I cannot test it. See here below a file with what written in vdsmd.log, with the two attempts and the failure and the loop of type Thread-61::DEBUG::2013-10-10 01:15:32,161::BindingXMLRPC::986::vds::(wrapper) return getCapabilities with {'status': {'message': 'Recovering from crash or Initializing', 'code': 99}} https://docs.google.com/file/d/0BwoPbcrMv8mvamR3RmpzLU11OFE/edit?usp=sharing