Pool Sharing Across Virtual Services

Starting with release 17.1.6, Avi Vantage supports the sharing of a single pool across multiple virtual services. The feature supports use cases wherein the same back-end servers are being used by different virtual services, each virtual service having its own purpose and properties. This article explains the feature’s capabilities, its CLI interface, and lists use restrictions.


In the past, a pool could be used by only one virtual service at a time. Each pool was exclusively “owned” by exactly one virtual service. In addition, a virtual service could own several pools. A virtual service might refer to a given pool through multiple techniques:

  • As the default pool defined for the VS
  • Through policy-based content-switching, a VS might choose one of its pools
  • Via DataScript, a VS might programmatically choose one of its pools

As of 17.1.6, a pool can be referenced by multiple virtual services. In accessing the shared pool, each VS can independently use any one of the multiple techniques listed above. As before, a virtual service may access multiple pools, some of them shared and others not. Virtual services sharing a pool need not be placed on the same SE group.

Summary: A virtual service can refer to any combination of shared and non-shared pools at any given time, utilizing multiple and different techniques.

Note: The current implementation supports sharing across simple pools only. Pool group sharing is planned for a future release.


Some of the following restrictions may be lifted in future releases.

  • Pool sharing is supported only for HTTP/HTTPs virtual services.
  • All virtual services sharing a pool need to be of the same application profile type.
  • Cookie persistence is the only persistence method.
  • Request queing, caching, compression and basic auth are not supported.
  • Connection multiplexing is supported, but all virtual services sharing the pool must be optioned identically with regard to connection multiplexing.
  • A pool group or pools that are part of a pool group cannot be shared.

Configuration and Reporting

Pool-related workflow is essentially the same as prior to the advent of pool sharing. The differences are:

  1. Users enjoy an increased number of pool choices when configuring a virtual service.
  2. There are more ways by which to extract pool-related information when querying for statistics.

Impact on the Avi UI User

Figure 1 illustrates the fact that pool sharing provides more choices when configuring a virtual service. In the past, pools already assigned to virtual services would not be offered as candidates for the algoApp-1 virtual service shown in the figure.

More pool choices Figure 1. Additional pool choices in the VS editor

Now that a given pool may serve more than one virtual service, displays such as the one shown in Figure 2 change.

Pool display now likely to show multiple virtual services Figure 2. Pool displays now likely to shown multiple virtual services

The ability for a single virtual service to be associated with multiple pools is unchanged. Figure 3 illustrates such a VS.

Virtual Service display continues to show multiple pools Figure 3. Virtual Service display continues to show multiple pools

Impact on the Avi CLI User

Configuration of a shared pool is no different than before.

Reporting has been expanded, as illustrated by the below command line examples.

  • Show stats for each server in the named pool, filtered by SE and virtual service.

  show pool <pool-name> server detail  filter <se-name> filter <vs-name>
  • Show stats for all servers in the named pool for each visual service placed on the given SE.

  show pool <pool-name> server detail  filter <se-name>
  • Aggregating across all SEs on which the named virtual service is placed, show stats for each server in the named pool.

  show pool <pool-name> server detail  filter  <vs-name>
  • For all virtual services placed on the SE group, and aggregating across all SEs, show stats for each server in the named pool.

  show pool <pool-name> server detail
  • Aggregating across all SEs on which the named virtual service is placed, show stats for the named pool.

  show pool <pool-name> detail  filter  <vs-name>

State of Virtual Services

When virtual services sharing the same pool are placed on multiple SEs, and each SE has different reachability to application servers in the back-end pool, the virtual service and the pool states reflect this. This is different from the state reported when a single virtual service is scaled out across Service Engines. One can check a pool’s operational capability with a show pool <shared-pool> summary command, which has percent_servers_up_enabled set to True. As an example, if 1 of the 2 SEs has no reachability to the back-end servers, then this would be 50%.

Virtual Service Placement

Unless specifically constrained, virtual services sharing the same pool can be placed on multiple Service Engines. If the virtual services are placed on multiple SEs in different SE groups (not to be confused with intra-SE-group scaleout), constraints such as max-connections are enforced on a per-SE-group of scaled-out SEs.

Virtual Service Events

Any operational events on the shared pool is reflected on all its virtual services’ contexts. However, when adding subsequent VSs (after the first VS is created and associated with a pool) to share the pool, the pool’s prior events will not be reflected on the subsequently added VSs. However, all future events will show up.

Metrics, Alerts and Health Score

Metrics, alerts and health score for the pool are an aggregate of the pool’s traffic/state across all virtual services. Service Engines do keep metrics information on a per-server, per-virtual-service basis. CLI commands/REST APIs can be used to get this information for troubleshooting purposes.