Each customer or tenant is provided with a vFabric that isolates their servers and nodes from others using PKeys. Each vFabric is defined in the opafm.xml configuration file, stating which servers and nodes belong to them through Device Groups.

In some cases, some shared resources may be required (for example, storage). As illustrated in the following figure, each tenant will have access to the nodes in this shared vFabric, but this will not create a path for one tenant to access another. This is achieved using Limited Membership. Limited Members of a PKey can access Full Members of that PKey but cannot access other Limited Members of that PKey. Thus, if the tenants are Limited Members of the shared vFabric's PKey, they can access the shared vFabric, but no other nodes through that PKey.

Figure 78. Example Multi-Tenancy Memberships

This means that a tenant node will have two PKeys: one for the tenant's own vFabric and one for the shared vFabric.

Typically, a CSP will need to add or remove tenants, or add or remove the servers belonging to existing tenants, on the fabric without affecting the other tenants. For this reason, use systemctl reload opafm to implement changes without completely restarting the FM.

As a framework for doing this, the file opafm_pp.xml is the fundamental FM configuration file. Each vFabric is created by making configuration fragments in the vfs directory (for vFabrics), and dgs directory (for the corresponding Device Groups). The opafmconfigpp command reads the opafm_pp.xml file and combines this with the fragments in vfs and dgs using the INCLUDE directives, and outputs a completed configuration file for the FM.

For convenience, the opafmvf command creates the fragments, runs opafmconfigpp, then runs systemctl reload opafm.