I am using vertx-jgroups, but it doesn't really matter which cluster manager is used. It can be off-platform and, as far i can see, Vert.x is using it mainly to store cluster map of discovered nodes. The main obstacle here is that once discovered, nodes need to be able to communicate directly with each other. This requires
Cloud Foundry's container-networking.
JGroups is more flexible in this respect, as it allows to tunnel cluster communication via a configured proxy(ies) host/port, so nodes in JGroups cluster don't have to communicate directly. This may not be as performant as direct communication though.
Without container-networking, everything should be proxied via front-door load balancer / TCP router... which starts looking like service discovery of Vert.x nodes.
I am thinking that to make it work, a mapped route to container is required and cluster map should be storing route's (host/port) for nodes to reach each other. Providing route's parameters in -cluster-host & -cluster-port doesn't work here as these are not local to container where vert.x is running (due to load balancing, NAT'ing and routing within Cloud Foundry) so Vert.x can't bind to them. It seems not difficult as long as mapped route identifies nodes uniquely (which i am not sure about as CF does some load balancing for the route to support scaling)... thoughts?