Just one more info: I have three GlusterFS volumes between the two nodes, and the first three migrations fail.

As qemu (or libvirt, not sure which one chooses the incomming migration port) increment the port number at each migration attempt, the fourth migration succeed (and the following migrations succeed too)

We just hit this bug in a new setup today.  Verifying this still exists.  
qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.7.x86_64
glusterfs-3.4.0-8.el6.x86_64
CentOS release 6.4 (Final)
Linux SERVERNAME 2.6.32-358.18.1.el6.x86_64 #1 SMP Wed Aug 28 17:19:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Same problem with oVirt 3.3 and fedora 19 as Hypervisors.
See here:
http://wiki.libvirt.org/page/FAQ
the range 49152-49215 already used by libvirt years before the Gluster change from 3.3 to 3.4...
How could you miss it and worse not able to change at least for 3.4.1 as this bugzilla was opened in July?

At least could you provide a way to configure gluster to use another range so that if two nodes are both servers and client they can use another range?

You are limiting GlusterFS adoption itself as noone would implement oVirt on GlusterFS without migration available...

Thanks for reading
Gianluca

Out of curiosity, why isn't this a bug in qemu-kvm? Shouldn't qemu-kvm be trying another port if 49152 (or any other port) is in use? And using portmapper to register the port it does end up using?

REVIEW: http://review.gluster.org/6076 (xlators/mgmt/glusterd: ports conflict with qemu live migration) posted (#1) for review on release-3.4 by Kaleb KEITHLEY (kkeithle)

From
http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
"
Dynamic, private or ephemeral ports[edit]

The range 49152–65535 (215+214 to 216−1) – above the registered ports – contains dynamic or private ports that cannot be registered with IANA.[133] This range is used for custom or temporary purposes and for automatic allocation of ephemeral ports.
"

[133]
https://tools.ietf.org/html/rfc6335

If a new projyect starts to use a range, in my opinion has to consider that it is not the only project in the world and/or for the future.... ;-)

Why libvirt and GlusterFS could not reserve via IANA so that /etc/services could be updated and other projects before set new range can query current status?

It seems very like the 192.168.1.x private network used by every one.
Latest reserved port 49151 and so why not? Start at 49152... ;-)

There are quite several ranges up to 65535 or not?

Just my two eurocent

So as

49152-65535 cannot be registered with IANA

why not try any range below 49151 that is still free or ask to IANA to extend or at least coordinate in an way to not overlap?
Thanks,
Gianluca

From http://review.gluster.org/6075:

Anand Avati		Oct 11 9:09 PM

Patch Set 1: Code-Review-1

Technically this change looks OK. I'm just concerned about the confusion this is going to cause to users who need to open up their firewalls. There is still confusion about what ports and what ranges need to be opened for 3.3 vs 3.4, and this change is only going to add to the confusion (worse if we get it into 3.4.x branch)

Niels de Vos		Oct 14 12:50 PM

Patch Set 1:

Instead of changing the defaults, is it acceptable to make the start port a configurable option in /etc/glusterd/glusterd.vol or similar?

Vijay Bellur		Oct 14 1:28 PM

Patch Set 1:

Providing a configurable start value for brick ports would be ideal here.

RFC 6335 is very clear about this:

   8.1.2. Variances for Specific Port Number Ranges
   ...
      o  Ports in the Dynamic Ports range (49152-65535) have been
         specifically set aside for local and dynamic use and cannot be
         assigned through IANA.  Application software may simply use any
         dynamic port that is available on the local host, without any sort
         of assignment.  On the other hand, application software MUST NOT
         assume that a specific port number in the Dynamic Ports range will
         always be available for communication at all times...

This is clearly a libvirt bug. Libvirt needs to handle the case when a port is not available. It cannot assume that it can exclusively use ports starting at 49152.

See Red Hat bugs 1018530, 1018696, and 1019237.

Re-opening so that we can consider providing a workaround for libvirt and other applications that cause this issue.

I am of the opinion that Gluster should not change the default port (49152), but add an option so that users can specify a different base-port if they need to.

An implementation from Kaleb that add an option in /etc/glusterd/glusterd.vol:
* http://review.gluster.org/6147

Comments in this Bug or the above Gerrit link are very welcome :)

REVIEW: http://review.gluster.org/6147 (mgmt/glusterd: add option to specify a different base-port) posted (#3) for review on release-3.4 by Kaleb KEITHLEY (kkeithle)

COMMIT: http://review.gluster.org/6147 committed in release-3.4 by Vijay Bellur (vbellur) 
------
commit 7c433629c35f729241423dacdff1e297731153fc
Author: Kaleb S. KEITHLEY <kkeithle>
Date:   Fri Oct 25 09:05:18 2013 -0400

    mgmt/glusterd: add option to specify a different base-port
    
    This is (arguably) a hack to work around a bug in libvirt which is not
    well behaved wrt to using TCP ports in the unreserved space between
    49152-65535. (See RFC 6335)
    
    Normally glusterd starts and binds to the first available port in range,
    usually 49152. libvirt's live migration also tries to use ports in this
    range, but has no fallback to use (an)other port(s) when the one it wants
    is already in use.
    
    libvirt cannot fix this in time for their impending release. This is
    submitted to gerrit to provide some minimal visibility upstream to justify
    hacking this change (as a temporary patch) into the glusterfs-3.4.1 RPMs
    for Fedora 18-21 until libvirt can fix their implementation.
    
    Change-Id: Ie77b00ac60730d1e48907dd0b38ddae92f3ac345
    BUG: 987555
    Signed-off-by: Kaleb S. KEITHLEY <kkeithle>
    Reviewed-on: http://review.gluster.org/6147
    Reviewed-by: Niels de Vos <ndevos>
    Tested-by: Niels de Vos <ndevos>
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Raghavan Pichai <rpichai>

Merged in the master (http://review.gluster.org/6210, bug 1018178) and release-3.4 branch.

Hello,
does comment#13 mean that this enhancement will be in upcoming 3.4.2 release?
When is it expected to be out? Any release schedule link?
Thanks,
Gianluca

(In reply to Gianluca Cecchi from comment #14)
> Hello,
> does comment#13 mean that this enhancement will be in upcoming 3.4.2 release?

Yes, when a new release is done, this option will be available.

> When is it expected to be out? Any release schedule link?

It's a little out-of-date, and does not contain a reference to 3.4.2:
- http://www.gluster.org/community/documentation/index.php/GlusterPlanning

Most recent communication went to the gluster-devel mailinglist:
- http://lists.nongnu.org/archive/html/gluster-devel/2013-11/msg00000.html

Packages are available for testing:
- http://lists.nongnu.org/archive/html/gluster-devel/2013-12/msg00091.html

From http://lists.nongnu.org/archive/html/gluster-devel/2013-12/msg00127.html:

> I upgraded to gluster 3.4.2qa4 (see above).
> VM still worked fine, bonnie++ tests from inside the VM instances showing 
> similar results than before
> but than I hit the 987555 bug again

The change for that bug introduces an option to the 
/etc/glusterfs/gluster.vol configuration file. You can now add the 
following line to that file:

  volume management
      ...
      option base-port 50152
      ...
  end-volume

By default this is commented out with the default port (49152). In the 
line above. 50152 is just an example, you can pick any port you like.  
GlusterFS tries to detect if a port is in use, if it is, it'll try the 
next one (and so on).

Also note that QEMU had a fix for this as well. With the right version 
of QEMU, there should be no need to change this option from the default.
Details on the fixes for QEMU are referenced in Bug 1019053.

Can you let us know if setting this option and restarting all the 
glusterfsd processes helps?

Verified by Bernhard Glomm:
- http://lists.nongnu.org/archive/html/gluster-devel/2013-12/msg00134.html

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.4.3, please reopen this bug report.

glusterfs-3.4.3 has been announced on the Gluster Developers mailinglist [1], packages for several distributions should already be or become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

The fix for this bug likely to be included in all future GlusterFS releases i.e. release > 3.4.3. In the same line the recent release i.e. glusterfs-3.5.0 [3] likely to have the fix. You can verify this by reading the comments in this bug report and checking for comments mentioning "committed in release-3.5".

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/5978
[2] http://news.gmane.org/gmane.comp.file-systems.gluster.user
[3] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/6137