Storage Access Groups (SAGs), introduced in Apache CloudStack 4.21, allow operators to restrict which Hosts connect to a specific Primary Storage. This feature replaces the default behaviour of connecting the Primary Storage to all Hosts within its scope, optimising resource utilisation, reducing load, and enforcing isolation policies in large-scale environments.
 

The Challenge of Broad Connectivity

In Apache CloudStack, the Primary Storage stores the root and data volumes of Virtual Machine Instances, making it essential for storing active workloads. Primary Storage ensures data persistence and supports key Instance operations such as booting, snapshots, and migrations.

When Primary Storage is added, whether at the Zone scope or the Cluster scope, it typically connects to all Hosts within that defined scope. While this is often the required behaviour, such broad connectivity can be unnecessary or inefficient. This inefficiency is most noticeably pronounced in large or heterogeneous environments, leading to potential network and storage traffic overhead.
 

What are Storage Access Groups (SAGs)

To address the limitations of the default ‘connect to all’ behaviour, Storage Access Groups were introduced, starting in version 4.21. SAGs allow Administrators to control and limit which Host connects to which Primary Storage.

Storage Access Groups (SAGs) are simple text attributes, simple text attributes, similar to tags, that can be assigned to the following CloudStack components:

• Primary storages
• Hosts
• Clusters, Pods, or Zones (allowing for automatic inheritance by contained Hosts)

 

Connectivity Logic

When a SAG is configured on both a Primary Storage and a Host, the Primary Storage will only establish a connection with that Host. This capability allows Administrators to define custom access topologies.

The connectivity rules are summarised as follows:

Storage Pool SAG Status	Host SAG Status	Connectivity Result
Configured with a SAG	Configured with the same SAG	Connects
Configured with a SAG	Configured with a different SAG or no SAG	Does not connect
Configured without a SAG	Configured with or without any SAG	Connects to all Hosts

 

Practical Application of SAGs

Consider an environment structured as follows:

• 50 Hosts spread across 10 Clusters (5 hosts per Cluster).
• A single Zone-wide Primary Storage.

By default, the Primary Storage will attempt to connect to all 50 hosts.

However, suppose the requirement is for the storage pool to connect only to specific Hosts, for instance, only those within the first two Clusters.

With SAGs, this limitation is enforced by:

1. Assign a SAG to the Primary Storage. Example: nfs-group-a.
2. Assign the same SAG to the desired Hosts. This can be done to the individual Hosts or applied at the Cluster level (or Pod or Zone level) for inheritance.

Following this configuration, only those Hosts matching the assigned SAG will establish a connection with the Primary Storage.

 

How to Configure SAGs

Configuration involves assigning the corresponding SAG string to the desired resources:

1. Assigning SAG to Primary Storage

The SAG field is set either during or after the creation of the Primary Storage.

• This process utilises the configureStorageAccess API.

2. Assigning SAG to Hosts (or Scope Levels)

The identical SAG string is applied to individual Hosts, or assigned at the Cluster, Pod, or Zone level so that all contained Hosts inherit the attribute.

• This process also utilises the configureStorageAccess API.

 

Management API

To facilitate easier management of configurations, the listStorageAccessGroups API is available. This API lists all SAGs that are already configured on the Primary Storages, which assists operators when assigning the corresponding SAGs to Hosts.
 

Conclusion

Storage Access Groups provide CloudStack operators with essential fine-grained control over Primary Storage connectivity. In environments characterised by large-scale or diverse infrastructure, this selective access mechanism is highly valuable for improving performance, reducing resource load, or effectively enforcing isolation policies.