vCMP and Chassis Management

F5 VIPRION is a chassis platform: a physical enclosure with hot-pluggable blades, running the vCMP (Virtual Clustered Multiprocessing) hypervisor so that a single chassis can host many independent guests — each a full, isolated BIG-IP instance with its own config, version, and management address. Versus treats a VIPRION chassis as a first-class device: it discovers the chassis, enumerates its blades and vCMP guests into inventory, reads their state, and can drive a controlled migration of guest workloads onto modern F5OS (VELOS / rSeries) tenants.

This page covers how the chassis model maps into Versus, how discovery and the collector operations work under the hood, and how the vCMP → F5OS migration plan cuts a workload over one HA unit at a time.

---

The chassis model in Versus

A VIPRION chassis is added as a device with vendor viprion ("F5 VIPRION Chassis"). Like F5OS, it classifies as a chassis device type — the box itself is a management plane that fronts many logical instances rather than a single traffic-serving appliance.

Once discovered, the chassis becomes the controller for a set of child records. Versus models blades and guests as ManagedDevice rows hanging off the chassis device, the same pattern used for AVI Service Engines or Panorama-managed firewalls:

Each child carries its own version, status, management IP (for guests), and a raw_data snapshot of what the device reported, plus a last_synced timestamp. Child records are keyed uniquely by (controller, name), so re-running discovery updates existing entries in place and prunes any blade or guest that no longer exists on the chassis.

---

Discovery and inventory

Discovery uses the VIPRIONClient, a thin extension of the standard F5 BIG-IP client. It speaks the same iControl REST protocol over HTTPS, authenticates with the same HTTP Basic Auth credentials, and reuses the same object-name handling — a VIPRION chassis answers on the familiar /mgmt/tm/... tree, just with chassis-specific subtrees layered on top. Because the transport is identical, no separate driver or credential type is needed; see F5 BIG-IP Integration.

The client reads these subtrees:

Discovery runs as a background import job so it never blocks the API. The job records step-by-step progress you can watch from the UI, and proceeds in stages:

1. System info — hostname, version, and license registration key from the chassis; HA status is reported as active because the chassis management plane is always reachable.
2. Blades — each slot is upserted as a blade child, with its bladeSoftwareVersion and status; slots that have gone away are removed.
3. vCMP guests — each guest is upserted as a guest child, recording its managementIp, state, and version.

When the job finishes, its log summarizes what landed — for example Import complete: 4 blades, 12 vCMP guests.

Guest specifications

For any guest, Versus can read its full sizing profile from /vcmp/guest/<name> and normalize the F5 field names into a stable shape:

{
  "name": "tenant-app-prod",
  "vcpu_cores": 4,        // coresPerSlot
  "memory_mb": 8192,      // memoryInMegabytes
  "disk_gb": 76,          // storageInGigabytes
  "vlans": [100, 200, 310],
  "mgmt_ip": "10.20.0.15",
  "state": "deployed",
  "version": "15.1.10"
}

These specs are what let a migration size the destination correctly — the target tenant is created with the same cores, memory, disk, and VLANs the guest was running with.

---

Reading the chassis through a collector

Where a collector fronts the chassis, the same reads (plus the safe writes) are available as discrete collector operations, dispatched outbound over the bearer-authenticated collector channel so Versus never needs an inbound path to the chassis. See Collector Security and Collector Fleet.

The chassis / vCMP operation catalog:

vcmp.guest_get and vcmp.guest_set_state take a guest_name argument, which is validated against the allowed object-name pattern before it is ever placed in a URL. For vcmp.guest_set_state, the requested state is checked against an allow-list of vCMP provisioning states (configured, provisioned, deployed) so the operation cannot be coerced into an arbitrary value. vcmp.failover issues a standby failover on the target (/sys/failover with { "command": "run", "standby": true }).

The heavier, file-transfer operations — saving and loading a UCS archive — are intentionally not exposed as collector ops; those run through the migration engine described below, where the config archive is handled server-side.

---

Migrating vCMP guests to F5OS

The most substantial chassis feature is a migration plan that moves a vCMP guest HA pair off legacy VIPRION hardware onto F5OS tenants (on VELOS or rSeries), one unit at a time, inside a change window, with no traffic outage. It lives under Workflows → Migrations → Hardware Migrations alongside the other ADC migration plans, and the same plan type also moves tenants from one F5OS host to another (see below).

The model

A VcmpMigrationPlan captures both sides of the move and the staging choices made ahead of time:

• Legacy hosts (legacy_host_1, legacy_host_2) — the source VIPRION vCMP HA pair.
• Target hosts (target_host_1, target_host_2) — the destination F5OS appliances.
• Selected guests, temporary management IPs (with prefix and gateway), and the tenant image chosen from the firmware library.
• Trunk mappings — how each legacy trunk's VLANs map onto an F5OS trunk.
• Preparation flags: tenants_created, vlans_staged, tenants_deployed.

Each side of the HA pair becomes a VcmpMigrationUnit — a source guest paired with the target tenant it maps to. The unit tracks a UCS size, a captured guest_specs, a pre-migration pool-member snapshot, a running log, and a state that advances through the cutover:

pending → offline → ucs_saved → guest_down → vlans_set
        → ucs_loaded → online → active

The plan itself moves draft → prepared → migrating → completed (or failed).

Phase 1 — Preparation (done ahead of the window)

Staging touches only the target and is non-disruptive:

create_tenants reads each guest's live specs and provisions a matching tenant — the same core count, memory, disk, temporary management IP, prefix, and gateway — so the destination is a faithful replica before any config moves. Tenants are laid out across the two target hosts so each unit's replacement lands on the correct side of the new pair.

Phase 2 — Migration (per unit, in the change window)

The cutover runs one unit at a time — the standby side first — through actions on the unit. Each step records its result to the unit log and advances the state:

When every unit reaches active, the plan is marked completed.

F5OS → F5OS (rSeries / VELOS to rSeries / VELOS)

The same plan handles a second source: tenants on an F5OS host instead of vCMP guests on a VIPRION. Pick F5OS → F5OS as the migration type when you create the plan — for a hardware refresh (r5000 to r10000), consolidating several appliances onto one, or moving tenants to a host at another site. The source hosts are then F5OS devices, "List Tenants" enumerates the source host's tenants through the F5OS API (image, cores, memory, disk, VLANs and management IP come from the tenant's config), and from tenant creation on the flow is identical: create the target tenants sized like the source, stage VLANs and map trunks/LAGs, then per unit snapshot pool members, drain, save the UCS, power the source tenant off (running-state provisioned, so it can be powered back on in one step if you need to roll back), assign VLANs, load the UCS on the target tenant, verify, compare pool members and fail over.

Two things differ from the VIPRION case:

• Tenant credential. An F5OS platform login does not work on its tenants, so the plan carries a tenant BIG-IP credential — the TMOS login used for the pool snapshot, drain, UCS save and cutover on the tenants themselves. (A VIPRION host and its guests usually share one, so the field is optional there.)
• Collector-managed hosts. When the source or target host is reached through a site collector, the tenant management addresses are relayed through that same collector, because tenant IPs are not devices Versus knows on their own.

Many hosts onto one? Use rSeries Consolidation. For a many-to-one move with capacity planning — several rSeries/VELOS (or VIPRION) sources drained onto one target with vCPU fit, VLAN-gap detection and remediation, HA-aware standalone/leapfrog moves and a change record — use Workflows → Migrations → rSeries Consolidation instead. It works from the chassis inventory Versus builds when an F5OS host is discovered (chassis, partition, blades, tenants with their sizing), so a freshly added rSeries host appears as a source or target once its discovery has completed. The Hardware Migration plan above is the one-pair-at-a-time cutover with an explicit UCS step; the consolidation planner is the estate-level move.

Plan and unit records are shared with the VIPRION flow (VcmpMigrationPlan.source_platform = viprion | f5os; the unit records the source tenant's management IP as source_mgmt_ip), so the API, the states and the unit log read the same for both.

DR mode in rSeries Consolidation

A consolidation plan moves tenants one at a time, HA-aware (standalone window or HA leapfrog), and each tenant keeps its name and management IP. A DR build-out is the opposite shape, so the consolidation planner has a second mode for it. Switch the new-plan screen from Consolidation to DR build-out and:

• Every staged guest is migrated at the same time. There is no HA leapfrog step and no sequencing — all the moves in the plan run together on the target host. The source tenants keep running untouched.
• Each copy gets its own identity. Every staged tenant card has a name and mgmt IP text box next to the vCPU box: the new tenant on the target is created with that name and that permanent management IP (the plan carries the management prefix length and gateway, and an optional tenant credential for logging in to the source tenants). Validation refuses a name or address that is already used on the target host, used twice in the plan, or equal to the source's own address.
• Run it from the plan page. Validate and compile as usual (a change record opens per tenant, with no sequencing wait), then Run DR cutover builds every ready tenant at once. Per tenant Versus saves a UCS from the source (falling back to the latest stored UCS backup when the source is already unreachable), creates the tenant on the target with the new name, IP and the source's VLANs, waits for its API, loads the UCS, then re-asserts the DR identity — hostname, cm device name and, when the platform did not keep it, the management IP inside TMOS — and records the new tenant in the chassis inventory. Progress and any warnings (for example device-trust config that must be rebuilt at the DR site) show on each move as it runs.

Target name and IP can still be edited on the plan page until the tenant starts building.

Tenant images are pre-staged by you, never copied by Versus. Each move needs its source tenant's TMOS image bundle (for example BIGIP-17.1.1.3-0.0.5.ALL-F5OS.qcow2.zip.bundle) on the target host. Import it in F5OS first (Tenant Deployments → Tenant Images → Import, file import on the CLI, or scp the bundle into the host's IMAGES/ directory) and wait for its status to reach verified. The plan page has a Tenant images panel that reads the target host live: it lists what the host has, marks each move's image as on host, missing or unverified, and a Refresh button re-checks after you have staged it. Validation blocks a move whose image is missing (an unreachable host reads as unverified, not missing, and the move re-checks at run time). A bundle with the same TMOS version under a different name is accepted.

UCS custody across a master-key boundary

Moving a UCS between two different appliances is the delicate part: a BIG-IP encrypts the secrets inside its UCS with a local master key, so a naive restore onto a different box cannot decrypt them. The migration supports saving the UCS with an optional passphrase that encrypts the archive independently of the source's master key, and loading it with the same passphrase on the target — the supported way to carry a config, secrets and all, onto hardware that does not already share the source's master key. The load also passes no-license and no-platform-check so the archive restores cleanly onto the differently-licensed F5OS tenant.

Because migration only ever disables the standby side before promoting its replacement — and captures a pool-member snapshot to diff against afterward — the active side keeps serving throughout, and each unit is independently verifiable before you move on to the next.

---

How it fits the platform

vCMP and chassis management is not a separate product surface — it reuses the same building blocks as the rest of Versus. The chassis is an ordinary device; blades and guests are ordinary inventory; the migration plan is an auditable, resumable set of API-driven steps in the spirit of the Workflow Builder. Credentials live in the Versus Vault, reads and safe writes can flow through a collector so no inbound path is required, and everything the chassis reports shows up in the same searches, dashboards, and reports as your standalone BIG-IPs and cloud edges. For the broader picture of how these layers compose, see Platform Architecture.

---

Related

• F5 BIG-IP Integration — the iControl REST driver the VIPRION client extends.
• Collector Security — outbound-only reach to chassis and guests.
• Collector Fleet — managing the collectors that front your devices.
• Secret Vault — where chassis credentials are stored.
• Certificates — certificate lifecycle across your ADC estate.
• Workflow Builder — the automation model migrations follow.
• Platform Architecture — how the pieces fit together.