Information About DPVM
You can use Dynamic Port VSAN Membership (DPVM) to dynamically assign VSAN membership to ports by assigning VSANs based on the device WWN. DPVM eliminates the need to reconfigure the port VSAN membership to maintain fabric topology when a host or storage device connection is moved between two Cisco SAN switches or two ports within a switch. It retains the configured VSAN regardless of where a device is connected or moved.
DPVM assignment is based on the port world wide name (pWWN) and node world wide name (nWWN). A DPVM database contains mapping information for each device pWWN/nWWN assignment and the corresponding VSAN. Cisco NX-OS checks the database during a device FLOGI and obtains the required VSAN details.
The pWWN identifies the host or device and the nWWN identifies a node that consists of multiple devices. You can assign any one of these identifiers or any combination of these identifiers to configure DPVM mapping. If you assign a combination, preference is given to the pWWN.
DPVM uses the Cisco Fabric Services (CFS) infrastructure to allow efficient database management and distribution.
DPVM Databases
The DPVM database consists of a series of device mapping entries. Each entry consists of a device pWWN or nWWN assignment along with the dynamic VSAN assigned. You can configure a maximum of 16,000 DPVM entries in the DPVM database. This database is global to the whole switch (and fabric) and is not maintained for each VSAN.
DPVM uses the following three databases:
- Configuration (config) database
-
Stores all configuration changes when CFS distribution is disabled. Changes to this database are reflected in the active DPVM database when you activate the DPVM config database.
- Active database
-
Represents the DPVM configuration that is currently active in the fabric.
- Pending database
-
Stores all configuration changes when CFS distribution is enabled. Changes to this database are reflected in the config or active DPVM database when you commit the DPVM pending database.
DPVM Database Distribution
DPVM can use CFS to distribute the database to all switches in the fabric to allow devices to move anywhere and keep the same VSAN membership.
Note |
You should enable CFS distribution on all switches in the fabric. |
Using the CFS infrastructure, each DPVM server learns the DPVM database from each of its neighboring switches during the ISL bring-up process. If you change the database locally, the DPVM server notifies its neighboring switches, and that database is updated by all switches in the fabric.
When you enable CFS distribution for DPVM, the DPVM configuration database is copied into the DPVM pending database. All changes to the DPVM configuration are now stored in the DPVM pending database and the feature is locked (that is, no other switch can make changes to the DPVM database until you commit the changes or discard the changes and free the CFS lock).
The DPVM pending database includes the following changes:
-
Adding, deleting, or modifying database entries.
-
Activating, deactivating, or deleting the configuration database.
-
Enabling or disabling autolearning.
CFS distributes these changes to all switches in a fabric when you commit the changes. You can also discard (abort) the changes at this point.
Database Merge
When you merge two independent fabrics into one fabric, DPVM attempts to merge the DPVM database (the configuration database and static (unlearned) entries in the active DPVM database). To ensure a successful database merge, follow these guidelines:
-
Verify that the activation status and the auto-learn status is the same for both fabrics.
-
Verify that the combined number of device entries in each database does not exceed 16000 entries.
Note |
If you do not follow these two conditions, the merge will fail. The next CFS distribution will forcefully synchronize the databases and the activation states in the fabric. |