Inside the Tenant¶
Once a tenant is deployed you can connect/communicate directly to one of its CLI, webUI, or API interfaces. At this layer you are interacting with TMOS, i.e. the experience should be almost identical to a vCMP guest with some minor exceptions. Day to day management of the tenant will use the same CLI (tmsh), API (iControl) and webUI as TMOS instances or hardware devices running within customer envronments today. If you are using vCMP today, then many of the concepts will be familiar. If you run and appliance or VIPRION in a bare metal mode, then there will be some differences as VELOS will be configured with at least one tenant, and lower layer configuration and stats will come from the F5OS layer.
In VIRPION with vCMP, VLANs are created at the vCMP host layer and added to physical interfaces or trunks. The VLANs are then assigned to a vCMP guest at creation time using the VLAN name. VLAN names are passed through to the vCMP guest as-is, meaning the names are unaltered.
VELOS follows a similar behavior as far as tenants inheriting VLANs from the F5OS layer. At tenant creation time the admin will assign VLANs to the tenant based on VLAN ID. In VIPRION a vCMP guest will inherit the VLAN names, and they will appear inside the tenant. The initial versions of VELOS passed VLAN IDs to the tenant but not the name (names were autogenerated), but as of F5OS-C version 1.1.2 the VELOS tenant will inherit the VLAN names just as a vCMP guest will. Below is a VELOS tenant showing the VLAN names being passed from the F5OS layer that the tenant was configured for:
These are the VLANs as they appear in the F5OS platform layer. Notice that the tenant does not see all VLAN’s, only the ones that are assigned to it by the administrator:
You can delete the VLANs inside the tenant and then recreate them with a new name, as long as the tag value remains the same. The tag value is what will connect it back to the VLAN in the F5OS platform layer. The Journeys migration tool relies on a UCS restore procedure inside the tenant, and this tool will create VLANs with their proper names, and as long as the tag matches the VLAN configured in the platform layer the VLANs will be connected.
The number of interfaces within a tenant will be based upon the number of vCPUs assigned to the tenant and the number of slots the tenant is running on. The screenshot below shows the interfaces inside the tenant lining up with the number of physical cores per slot. In the first example there are 6 vCPUs on a single slot tenant, this will equate to 3 physical CPUs. Likewise for a dual slot tenant with 10 vCPUs per slot. You’ll see 5 physical CPU’s per slot.
Trunk / HA Group Behavior¶
Within a vCMP guest Trunks can be used as part of the HA Group functionality to determine when a guest should fail over to its peer.
An HA group is a specification of certain pools, host trunks, or cluster members (blades) or any combination of these that a guest administrator associates with a traffic group instance. The most common reason to configure an HA group is to ensure that failover is triggered when some number of trunk members or cluster members become unavailable.
Note: The initial versions of VELOS did not support the trunk option within an HA group. VELOS tenants will not have visibility into the trunks (LAGs in F5OS) configured at the platform layer. This feature has been added in F5OS v1.2.x and also requires the VELOS tenant be running v15.1.4.