By selecting the Customize option on the General tab, you can specify information about the pool members such as the port on which the members receive traffic, the protocol type that the NSX load balancer can use for accessing that port, the algorithm used for load balancing, and persistence settings.

A pool represents a cluster of machines that are being load balanced. A pool member represents one machine in that cluster.

The default member protocol and member port settings match the protocol and port settings on the General page.

The pool of member machines is shown in the Member option value in the blueprint load balancer component user interface. The Member entry is set to the pool or cluster of machines.


(Optional) The Member protocol setting matches the protocol that you specified on the General tab. This setting defines how the pool member is to receive network traffic.


(Optional) Enter a port number in the Member port text box to specify the port on which the pool member is to receive network traffic.

For example, if the incoming request on the load balancer virtual IP address (VIP) is on port 80, you might want to route the request to another port, for example port 8080, on the pool members.


(Optional) Select the algorithm balancing method for this pool.

The algorithm options and the algorithm parameters for the options that require them are described in the following table.


Description and algorithm parameters


Each server is used in turn according to the weight assigned to it.

If the load balancer was created in vRealize Automation, the weight is the same for all members.

This is the smoothest and fairest algorithm when the server's processing time remains equally distributed.

Algorithm parameters are disabled for this option.


Selects a server based on a hash of the source IP address and the total weight of all the running servers.

Algorithm parameters are disabled for this option.


Distributes client requests to multiple servers based on the number of connections already on the server.

New connections are sent to the server that has the fewest connections.

Algorithm parameters are disabled for this option.


The left part of the URI (before the question mark) is hashed and divided by the total weight of the running servers.

The result designates which server receives the request. This ensures that a URI is always directed to the same server as long as no server goes up or down.

The URI algorithm parameter has two options -- uriLength=<len> and uriDepth=<dep>. Enter the length and depth parameters on separate lines in the Algorithm parameters text box.

Length and depth parameters are followed by a positive integer number. These options can balance servers based on the beginning of the URI only.

The length parameter indicates that the algorithm should only consider the defined characters at the beginning of the URI to compute the hash. The length parameter range should be 1<=len<256.

The depth parameter indicates the maximum directory depth to be used to compute the hash. One level is counted for each slash in the request. The depth parameter range should be 1<=dep<10.

If both parameters are specified, the evaluation stops when either parameter is reached.


The HTTP header name is looked up in each HTTP request.

The header name in parenthesis is not case sensitive which is similar to the ACL 'hdr()' function.

The HTTPHEADER algorithm parameter has one option headerName=<name>. For example, you can use host as the HTTPHEADER algorithm parameter.

If the header is absent or does not contain any value, the round robin algorithm is applied.


The URL parameter specified in the argument is looked up in the query string of each HTTP GET request.

The URL algorithm parameter has one option urlParam=<url>.

If the parameter is followed by an equal sign = and a value, then the value is hashed and divided by the total weight of the running servers. The result designates which server receives the request. This process is used to track user identifiers in requests and ensure that a same user ID is always sent to the same server as long as no server goes up or down.

If no value or parameter is found, then a round robin algorithm is applied.


(Optional) Select the persistence method for this pool.

Persistence tracks and stores session data, such as the specific pool member that serviced a client request. With persistence, client requests are directed to the same pool member for the life of a session or during subsequent sessions.


Persistence method supported


None, Cookie, Source IP


None, Source IP and SSL Session ID


None, Source IP, MSRDP


None, Source IP

Select Cookie to insert a unique cookie to identify the session the first time a client accesses the site. The cookie is referred in subsequent requests to persist the connection to the appropriate server.

Select Source IP to track sessions based on the source IP address. When a client requests a connection to a virtual server that supports source address affinity persistence, the load balancer checks to see if that client previously connected, and if so, returns the client to the same pool member.

Select SSL Session ID to support one of the following supported HTTPS traffic patterns:

SSL Passthrough - Client -> HTTPS-> LB (SSL passthrough) -> HTTPS -> server

Client - HTTP-> LB -> HTTP -> servers

Select MSRDP to maintain persistent sessions between Windows clients and servers that are running the Microsoft Remote Desktop Protocol (RDP) service. The recommended scenario for enabling MSRDP persistence is to create a load balancing pool that consists of members running the supported Windows Server, where all members belong to a Windows cluster and participate in a Windows session directory.

Select None to specify that session actions are not stored for subsequent recall.


If you are using a cookie persistence setting, enter the cookie name.


(Optional) Select the mode by which the cookie is inserted from the Mode drop-down menu.




The NSX Edge sends a cookie.

If the server sends one or more cookies, the client receives an extra cookie (the server cookie(s) + the NSX Edge cookie). If the server does not send a cookie, the client receives the NSX Edge cookie.


The server sends a cookie. Use this option if your client does not support more than one cookie.

If you have a proprietary application using a proprietary client that supports only one cookie, the Web server sends a cookie but the NSX Edge injects (as a prefix) its cookie information in the server cookie value

App Session

The server does not send a cookie. Instead, it sends the user session information as a URL.

For example,;jsessionid=X000X0XXX0XXXX, where jsessionid is the user session information and is used for persistence.


(Optional) Enter the persistence expiration time for the cookie in seconds.

As an example, for L7 load balancing with a TCP source IP, the persistence entry times out if no new TCP connections are made for the specified expiration time, even if the existing connections are still live.


(Optional) Click the Health Check tab and proceed to the Define Virtual Server Health Check Settings topic to continue defining the virtual server in the NSX load balancer component.