Virtual System Deployment and Configuration
Deployment and Configuration tests the build sequence: planning VSIDs and interfaces, creating the VSX gateway or cluster object, provisioning virtual systems, and assigning interfaces without breaking isolation.
Build order that works
- Confirm licensing and platform role. A VSX Gateway is standalone; a VSX Cluster has member objects, a cluster VIP, and a dedicated sync network.
- Create the VSX gateway or cluster object in SmartConsole before creating tenant VS objects. The platform object defines management connectivity, interfaces, and the provisioning profile.
- Provision VSs from the gateway object. The provisioning profile controls how many virtual systems and how much memory each receives; plan VSID allocation so it stays stable across rebuilds.
- Configure physical interfaces, VLANs, bonds, and the management interface in Gaia or through the gateway object. Reserve the management interface for platform traffic and the sync interface for cluster traffic.
- For each VS, assign external and internal interfaces, set IPv4 addressing, attach the policy package, and install policy to that VS.
Worked example
A PCI zone needs a new VS on a two-member VSX cluster. Allocate VSID 5, external VLAN 205, internal VLAN 305. Create the VS object with VSID 5, assign VLAN 205 and VLAN 305, set addressing, and attach the PCI policy package. Confirm the cluster VIP is reachable from the external VLAN, then install policy to VS 5 only. Validate with VSX status commands such as vsx stat -v and test traffic from the internal VLAN.
Traps that cost marks
- Creating a VS without a unique VSID or reusing a VSID from a removed system.
- Assigning the same untagged interface to multiple VSs, which collapses separation.
- Forgetting the cluster VIP or sync network, so failover works for the platform but not for tenant traffic.
- Using the management interface for tenant data.
- Installing policy before interfaces and routing are correct, then blaming the rule base.