Tenant Management

Tenant Management

Tenants overview

A tenant is a guest system running software in a chassis partition (for example, a BIG-IP system). VELOS systems support multitenancy, in that you can run several tenants in the same chassis partition, including BIG-IP and BIG-IP Next tenants. The maximum number of lightweight tenants that can be created in a blade is 22. Each blade has 128GB memory, of which 95GB is reserved for tenants. Each lightweight tenant requires a minimum of one vCPU and 4096MB minimum memory.

Note: Information about BIG-IP Next is available on my.f5.com, on clouddocs.f5.com, and in the article How to: Configure multi-tenancy for BIG-IP Next on VELOS.

The administrator can connect to the tenant’s webUI, CLI, or REST API and have the same experience as on their existing F5 platforms. A tenant on the VELOS platform is managed similarly to how a vCMP guest is managed today on the VIPRION platform. The tenant is assigned dedicated vCPU and memory resources and is restricted to specific VLANs for network connectivity.

The chassis partition administrator is responsible for configuring tenant deployments within the chassis partition. Once a tenant has been deployed, there is a per-tenant administrator role, whose responsibilities include configuring the services that are available on that tenant.

The admin is responsible for configuring tenant deployments within the appliance. Once a tenant has been deployed, there is a per-tenant administrator role, whose responsibilities include configuring the services that are available on that tenant.

Important: Tenants inherit certain capabilities, such as the license, VLANs, and management interface speed, from the chassis partitionsystem. Do not try to install a new license or delete the existing license on the tenants. Tenant admins cannot configure global partition-wide parameters. You configure these at the platform layer, and values are propagated to all tenants in the chassis partitionsystem.

Also see knowledge article Overview of the BIG-IP tenant image types

Note: Consider the following points while referring to the term slot:

• Scenario1: Here, the term slot refers to the number of boot locations inside a TMOS image. Images can be either single slot or dual slot. Single slot image has only one boot location and does not support in-place upgrades. Dual slot images will have 2 boot locations and supports in-place upgrades to different TMOS versions.
• Scenario 2: When deploying an F5OS tenant on VELOS, you can select the physical slots in the chassis that you want a tenant to run on. Here the term slot is used instead of the term blade, because you can pre-configure to run on a slot which does not have a blade installed yet.

This table lists tenant data specifications for VELOS systems.

Tenant data

This table lists tenant data specifications for VELOS systems.

Tenants in a chassis partition example

In this diagram, a VELOS CX410 chassis is divided into three chassis partitions (Red, Green, and Blue). These chassis partitions are completely isolated from each other, and the system controllers ensure that no traffic can jump from one chassis partition to another. After creating a chassis partition, you can deploy individual tenants. These tenants are restricted only to the resources within that chassis partition.

In the figure, the Red and Blue chassis partitions each span two blades and both have four tenants residing on them. The Green chassis partition spans four blades and has one tenant, Tenant 9, on it. Presumably, Tenant 9 is handling a large amount of traffic and requires more bandwidth and more processing power than the other tenants.

Tenant image overview

BIG-IP tenant images

These BIG-IP tenant images are available to deploy on F5 VELOS systems:

• ALL-F5OS
• T4-F5OS
• T2-F5OS
• T1-F5OS (see note)

Note: T1-F5OS has limitations, so using the other images is recommended. Other images must be downloaded from F5 Downloads.

Each image type has different uses so you need to be sure to use the correct type for your tenant needs. For additional information about BIG-IP tenant image types, see K45191957: Overview of the BIG-IP tenant image types.

BIG-IP Next tenant images

Information about BIG-IP Next tenant image types is available on my.f5.com.

This table lists general use cases for BIG-IP tenant images. Information about BIG-IP Next tenant images is available on my.f5.com.

Each image has different sizing requirements. You will need to understand the size of the chassis partition and the tenant requirements to determine the number and type of tenants you can deploy. The amount of memory and disk space that a tenant actually needs is dependent on the number of modules provisioned and its use. This table provides information about BIG-IP tenant sizing. For information about BIG-IP Next tenant sizing, see my.f5.com.

Tenant usage

This table lists general use cases for BIG-IP tenant images. Information about BIG-IP Next tenant images is available on my.f5.com.

Tenant sizing

Each image has different sizing requirements. You will need to understand the size of the chassis partition and the tenant requirements to determine the number and type of tenants you can deploy. The amount of memory and disk space that a tenant actually needs is dependent on the number of modules provisioned and its use. This table provides information about BIG-IP tenant sizing. For information about BIG-IP Next tenant sizing, see my.f5.com.

Important: The minimum virtual disk size for the tenant image category “ALL-F5OS” depends on the BIG-IP tenant image version you deploy.

• BIG-IP 17.1.3 and later: 83 GB
• BIG-IP 17.1.0 – 17.1.2: 82 GB
• BIG-IP 15.1.x: 77 GB

Tenant resource allocation considerations

These are recommended resource considerations for determining the amount of memory (RAM) to allocate when planning tenant deployments on VELOS systems:

• Each VELOS blade has up to 95GB of memory that can be allocated to tenants.

• The minimum memory allocation for a tenant depends on the number of vCPUs requested.

• This formula is used for default memory allocation

  Copy

  min-memory = (3.5 * 1024 * vcpu-cores-per-node) + 512

• You can specify more than the minimum amount of memory when configuring a tenant, if needed.

These are some of the resource considerations for disk space when planning tenant deployments on VELOS systems:

• Each VELOS blade has approximately 600GB of disk storage available for tenants.
• The amount of disk space that a tenant actually needs is dependent on the number of modules provisioned and its use.
• As the aggregate disk usage within deployed tenants increases, the host disk can start to reach capacity on systems with many large tenants. The chassis partition administrator will need to monitor disk usage to make sure there is sufficient space for the tenants.

Tenant management from the webUI

Manage tenant images from the webUI

You can add or delete tenant images within a chassis partition from the chassis partition webUI. You must use HTTPS image import or export. Note that tenant images are specific to the VELOS system, and the software version must be compatible with it.

1. Log in to the VELOS chassis partition webUI using an account with admin access.

2. On the left, click TENANT MANAGEMENT > Tenant Images.

3. To upload an image, click Upload and browse to the image location.

4. To import an image:

   1. Click Import.

      A popup opens.

   2. For URL, enter the URL of the remote image server.

      F5 recommends that the remote host be an HTTPS server with PUT/POST enabled and have a valid CA-signed certificate. You can opt to select the Ignore Certificate Warnings check box if you want to skip the certificate check.

   3. For Username, type the user name for an account on the remote image server, if required.

   4. For Password, type the password for the account, if required.

   5. Select Ignore Certificate Warnings to skip the certificate check.

   6. Click Import Image.

   Note: Depending on the image file size and network availability, the import might take a few minutes. If you want to cancel the in-progress file transfer operation, click Cancel. When the import is successful, the software image is listed in the webUI.

5. To delete a tenant image, select the image and click Delete. It is recommended that you wait 5-10 minutes after deleting a tenant before deploying another tenant.

After you have added the tenant images that you want to use to the chassis partition, you can create and deploy tenants that will use that software image. The tenant image must be one that is listed as compatible with the VELOS system.

Create and deploy tenants from the webUI

Before you get started, be sure that you have already imported the tenant images that you want to use for the tenant deployments into the chassis partition. You need to know into which slots you want to deploy the tenant. You must also have previously created any required VLANs in the chassis partition. Before you can create and deploy tenants, you also need to estimate resource requirements so you know how many vCPUs, memory, and other options to assign to the tenant.

The chassis partition administrator can deploy tenants from the chassis partition webUI.

1. Log in to the VELOS chassis partition webUI using an account with admin access.

2. On the left, click TENANT MANAGEMENT > Tenant Deployments.

   The Tenant Deployment screen displays showing the existing tenant deployments and associated details.

3. To add a tenant deployment, click Add.

   The Add Tenant Deployment screen displays.

4. For Name, enter a name for the tenant deployment (up to 49 characters).

   Note: The first character in the name cannot be a number. After that, only lowercase alphanumeric characters and hyphens are allowed.

5. For Type, select the tenant type: BIG-IP or BIG-IP Next.

   If you select BIG-IP Next, the Deployment File field displays. Select the deployment file.

6. For Image, select the software image that was previously imported onto the system.

   Ensure that the image you selected meets your tenant deployment needs.

7. For Allowed Slots, first select the appropriate option, and then select the slots (or blades) that you want the tenant to span from the list:

   Option	Description
   Partition Member Slots	Lists only slots included in the chassis partition you are logged into.
   Any Slots	Lists any slot on the chassis even if not associated with the chassis partition, and even if no blade is installed in that slot. You have the option of selecting slots 1-8 whether or not they are associated with the chassis partition. This enables you to preconfigure tenant deployments before the hardware is installed and before the chassis partition is configured to include it.

8. For IP Address, enter the IPv4 address, IPv6 address, or Fully Qualified Domain Name (FQDN) for the tenant.

9. For Prefix Length, enter a number for the length of the prefix.

   The maximum prefix length is 32 for IPv4 and 128 for IPv6.

10. For Gateway, enter the IPv4 address or IPv6 address of the gateway.

11. For VLANs, select one or more VLANs that are available to the tenant.

    You can assign VLANs to more than one tenant in the same partition.

12. For MAC Data/MAC Block Size, select one of these options:

13. For DAG IPv6 Prefix Length, enter the prefix length used by disaggregator algorithms.

    The range is from 1 to 128, with a default value of 128.

For more information about the prefix length, see Configure DAG IPv6 prefix length from the CLI.

14. For Resource Provisioning, select one of these options:

    Option	Description
    Recommended	Recommended values for vCPUs and memory for the tenant.
    Advanced	Enables you to configure custom values for vCPUs and memory on the tenant. For example, if you want to configure a single vCPU tenant, or a tenant that uses more than the recommended amount of memory per slot.

15. For vCPUs Per Slot, select the number of vCPUs to provide to the tenant.

    The minimum recommended number of vCPUs per typical tenant is two (one vCPU is sufficient only for lightweight tenants that cannot be updated). Each blade has up to 22 vCPUs. The number of vCPUs needed depends on the amount of traffic the tenant will be handling. More vCPUs provide faster throughput.

16. For Memory Per Slot, specify the amount of RAM, in MB, to allocate to the tenant.

    The amount of memory needed depends on the number of vCPUs assigned. The minimum amount of memory needed is determined by the formula [(3.5 * 1024 * #ofvCPUs) + 512], so a two vCPU tenant needs a minimum of 7680 MB, and a four vCPU tenant needs a minimum of 14,848MB.

    If you do not allocate sufficient memory, you receive a warning message.

17. For Virtual Disk Size, specify the storage quota, in GB, for the tenant virtual disk.

    The default size is 82 GB.

18. For State, select one of these options:

19. For Crypto/Compression Acceleration, select Enabled if the tenant requires high-performance crypto processing and compression.

    When this option is enabled, the tenant receives dedicated crypto devices proportional to number of vCPU cores. Crypto processing and compression are off-loaded to the hardware. When the option is disabled, the tenant receives no crypto devices. This is not supported on BIG-IP Next.

20. To restrict usage of the Bash shell for tenant administrators, set Appliance Mode to Enabled (this is Disabled by default.)

21. Click Save & Close.

The tenant is now configured and in the Deployed state. When the status says Running, the tenant administrator can log in to the tenant webUI or CLI using the management IP address (with HTTPS or SSH) and continue configuring the tenant system.

Note: If the Status says Pending instead of Running, this may mean that there are not enough resources (vCPUs, memory, or other resources) for the tenant to be deployed. See the Tenant Details screen in the chassis partition webUI for more information about the specific tenant.

Modify tenant deployments from the webUI

Depending on the state that the tenant is in, you can change certain tenant settings from the chassis partition webUI. The settings which cannot be modified will be grayed out.

• Deployed: You can add or remove Allowed Slots or change the State only while tenants are active and running.

  Note: Once a tenant is Deployed (and is up and running), changing its state back to Provisioned or Configured stops the tenant. You will receive a warning message before this occurs.

• Provisioned: You can change all settings exceptImage.

• Configured: You cannot change any settings once the tenant has been configured.

1. Log in to the VELOS chassis partition webUI using an account with admin access.

2. On the left, click TENANT MANAGEMENT > Tenant Deployments.

   The Tenant Deployment screen displays showing the existing tenant deployments and associated details.

3. Click the name of the tenant deployment you want to modify.

   The Tenant Deployment screen displays.

4. For Image, select a different software image to use for the tenant.

   Note: Only BIG-IP Next Tenant image can be modifed when the tenant is in deployed state, which essentially upgrades the tenant

5. To update Allowed Slots, select the slots (or blades) that you want the tenant to span from the list.

6. You can change the IP Address, Prefix Length (1-32), and Gateway for the tenant, if in Configured or Provisioned state. Enter an IPv4 address or IPv6 address.

7. For VLANs, you can select different VLANs for the tenant, if in Configured or Provisioned state.

8. For Resource Provisioning, if changing resources, select either: Recommended (to use recommended values) or Advanced (to customize values), if in Configured or Provisioned state.

9. For vCPUs Per Slot, select the number of vCPUs for the tenant, if in Configured or Provisioned state.

   The minimum recommended number of vCPUs per typical tenant is two (one vCPU is sufficient only for lightweight tenants that cannot be updated). Each blade has up to 22 vCPUs. The number of vCPUs needed depends on the amount of traffic the tenant will be handling. More vCPUs provide faster throughput.

10. For Memory Per Slot, specify the amount of RAM in MB to allocate to the tenant, if in Configured or Provisioned state.

    The amount of memory needed depends on the number of vCPUs assigned. The minimum amount of memory needed is determined by the formula [(3.5 * 1024 * #ofvCPUs) + 512], so a two vCPU tenant needs a minimum of 7680 MB, and a four vCPU tenant needs a minimum of 14,848MB.

11. Change State (with caution!):

    Option	Description
    Configured	If tenant has been Provisioned or Deployed, the virtual disk is deleted.
    Provisioned	If Deployed, this option stops the tenant from running, but maintains the configuration. If Configured, causes the system to install the software, assign the tenant to nodes, and create virtual disks for the tenant on those nodes. The tenant does not run, consume resources, or pass traffic.
    Deployed	Directly deploy the tenant. This sets up the tenant, allocates resources, moves the image onto the blade, and installs the software. When these tasks are complete, the tenant is fully deployed and running.

12. Change Crypto/Compression Acceleration only if the tenant is in either the Configured or Provisioned state.

13. To restrict usage of the Bash shell for tenant administrators, set Appliance Mode to Enabled (this is Disabled by default.)

14. Click Save & Close.

The tenant is reconfigured according to the changes made.

Enable appliance mode on tenants

You can enable appliance mode for deployed tenants from the chassis partition webUI.

Note: For greater security, consider configuring tenants to run in appliance mode.

1. Log in to the VELOS chassis partition webUI using an account with admin access.

2. On the left, click TENANT MANAGEMENT > Tenant Deployments.

   The Tenant Deployment screen displays showing the existing tenant deployments and associated details.

3. Click the name of a tenant deployment.

4. Set Appliance Mode to Enabled.

5. Click Save.

Root or Bash access is disabled on the tenant. Users can still access the tenant from the webUI or the CLI.

Display tenant status and statistics from the webUI

You can monitor data and metrics related to the usage, performance, and behavior of the tenant from the webUI. These statistics are crucial for monitoring, managing, and optimizing the tenant. You can monitor the following tenant details:

• Tenant CPU Usage: Shows the measurement of CPU utilization by the tenant.
• Tenant Memory Usage: Shows the measurement of memory utilization by the tenant.
• Tenant Disk Usage: Shows the measurement of disk utilization by the tenant.

1. Log in to the VELOS chassis partition webUI using an account with admin access.

2. On the left, click TENANT MANAGEMENT > Tenant Details.

3. Select a tenant from the Tenant Name dropdown to see the tenant status and statistics.

   You can now see the following statistics and status of the tenant.

   • Tenant CPU Usage: Displays the tenant’s vCPU’s current utilization by default. However, if multiple vCPUs are available, you can select a vCPU and change the time series to view the historical data and analyze the vCPU utilization.
   • Tenant Memory Usage: Displays the tenant’s current memory utilization by default. However, you can change the time series to view ‌historical data and analyze ‌memory utilization.
   • Tenant Disk Usage: Displays the overall tenant disk current utilization by default. However, if you need the utilization stats of a specific disk, select the disk, data type, and change the time series to view the historical data and analyze the disk utilization.
   • Tenant Status: Shows the overall status of the tenant image such as Node, Instance ID, Phase, Pod name, Creation time, Ready time, Status, and Management MAC details.

4. Select the interval from the Auto Refresh dropdown to refresh the data displayed or click the refresh icon to update the tenant data immediately.

   Note: The utilization data does not depend on the refresh interval. It will continue to collect utilization statistics for the tenant regardless of the selected reload interval.

Tenant management from the CLI

Use the tenants command from the chassis partition CLI to configure tenants on a chassis partition.

Import a tenant image from the CLI

Before you get started, you might want to upload the tenant image you want to use to a local Linux server that uses HTTPS, so you can more easily import it to the VELOS system.

You can import a tenant image into a chassis partition from the CLI.

1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

   When you log in to the system, you are in user (operational) mode.

2. Import a tenant image to the chassis partition.

   file import remote-port <*port-number*> username <*user*> password <*password*> remote-host <*ip-address-or-fqdn*> remote-file <*remote-file-path*> remote-url <*full-remote-url*> local-file images

   This example imports a BIG-IP tenant image from server.company.com:

   Copy

   default-1(config)# file import username admin password remote-url 
     https://server.company.com/images/BIGIP-1x.x.x-x.x.x.ALL-F5OS.qcow2.zip.bundle 
     local-file images

Create and deploy tenants from the CLI

Before you get started, be sure that you have already imported the tenant images that you want to use for the tenant deployments into the chassis partition. You need to know into which slots you want to deploy the tenant. You must also have previously created any required VLANs in the chassis partition. Before you can create and deploy tenants, you also need to estimate resource requirements so you know how many vCPUs, memory, and other options to assign to the tenant.

You can create and deploy tenants in a chassis partition from the CLI.

1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

   When you log in to the system, you are in user (operational) mode.

2. Change to config mode.

   config

   The CLI prompt changes to include (config).

3. Create and deploy the tenant.

   tenants tenant <*tenant-name*> config <*options*>

   For more information about CLI options, see Tenant CLI command syntax.

   This example creates a BIG-IP tenant named velos-bigip that spans two nodes and is in the Configured running state, by default:

   Copy

   default-1(config)# tenants tenant velos-bigip config type BIG-IP image  
     BIGIP-1x.x.x-x.x.x.ALL-F5OS.qcow2.zip.bundle mgmt-ip 192.0.2.200
     prefix-length 24 gateway 192.0.2.254 nodes [ 1 2 ]

   For more information about DAG IPv6 prefix length, see Configure DAG IPv6 prefix length from the CLI.

4. Commit the configuration changes.

   commit

5. Monitor the operational state of the tenant and move the tenant into the provisioned state.

   tenants tenant <*tenant-name*> config running-state provisioned

   This example moves the tenant into the provisioned state, which causes the system to start and maintain VMs on each node to which the tenant is assigned.

   Copy

   default-1# tenants tenant velos-bigip config running-state provisioned

   This causes the system to assign the tenant to nodes and create virtual disks for the tenant on those nodes.

6. Show the current status for the tenant:

   show tenants tenant <*tenant-name*>

   When the system is creating the virtual disk and installing the image on a disk, the operational state of the tenant shows this information:

   • PHASE – Allocating resources to the tenant is in progress
   • status – Provisioning A summary similar to this example displays:
   Copy

   default-1# show tenants tenant velos-bigip
   tenants tenant velos-bigip
    state unit-key-hash oa9gv8VYHcSoApv1234GQMn2uM9UzNKiDz78cIbqKv26LVjlIo9TCdp56z5UnXcVvr3hj0/ym2kbdWyBhPbkLA==
    state type          BIG-IP
    state image         BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
    state nodes         [ 1 2 ]
    state mgmt-ip       192.0.2.59
    state prefix-length 24
    state gateway       192.0.2.254
    state cryptos       enabled
    state vcpu-cores-per-node 2
    state memory        7680
    state storage size 76
    state running-state deployed
    state mac-data base-mac 00:94:a1:8e:70:0a
    state mac-data mac-pool-size 1
    state appliance-mode disabled
    state status        Provisioning
    state image-version "BIG-IP 15.1.5 0.0.222"
    state instances instance 1
     instance-id   1
     phase         Running
     image-name    BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
     creation-time 2022-12-01T19:56:49Z
     ready-time    2022-12-01T19:56:49Z
     status        "Allocating resources to tenant is in progress"
     mgmt-mac      f2:48:a7:f1:aa:ab
    state instances instance 2
     instance-id   2
     phase         Running
     image-name    BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
     creation-time 2022-12-01T19:56:50Z
     ready-time    2022-12-01T19:56:50Z
     status        "Allocating resources to tenant is in progress"
     mgmt-mac      f2:48:a7:f1:aa:ab

   When the system completes the virtual disk creation, the operational state shows this information:

   • PHASE – Ready to deploy
   • status – Provisioned A summary similar to this example displays:
   Copy

   default-1# show tenants tenant velos-bigip
   tenants tenant velos-bigip
    state unit-key-hash oa9gv8VYHcSoApv1234GQMn2uM9UzNKiDz78cIbqKv26LVjlIo9TCdp56z5UnXcVvr3hj0/ym2kbdWyBhPbkLA==
    state type          BIG-IP
    state image         BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
    state nodes         [ 1 2 ]
    state mgmt-ip       192.0.2.59
    state prefix-length 24
    state gateway       192.0.2.254
    state cryptos       enabled
    state vcpu-cores-per-node 2
    state memory        7680
    state storage size 76
    state running-state deployed
    state mac-data base-mac 00:94:a1:8e:70:0a
    state mac-data mac-pool-size 1
    state appliance-mode disabled
    state status        Provisioned
    state image-version "BIG-IP 15.1.5 0.0.222"
    state instances instance 1
     instance-id   1
     phase         "Ready to deploy"
     image-name    BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
     creation-time ""
     ready-time    ""
     status        " "
    state instances instance 2
     instance-id   2
     phase         "Ready to deploy"
     image-name    BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
     creation-time ""
     ready-time    ""
     status        " "

7. You can then deploy the tenant.

   tenants tenant <*tenant-name*> config running-state deployed

   This example moves the tenant into the deployed state, which causes the system to start and maintain VMs on each node to which the tenant is assigned.

   Copy

   default-1# tenants tenant velos-bigip config running-state deployed

8. Commit the configuration changes.

   commit

9. You can check the status of the tenant.

   show tenants tenant <*tenant-name*> state instances

   A summary similar to this example displays:

   Copy

   default-1# show tenants tenant velos-bigip state instances
         INSTANCE
   NODE  ID        PHASE    IMAGE NAME          CREATION TIME     READY TIME        STATUS                  MGMT...
   ----------------------------------------------------------------------------------------------------------------
   1     1         Running  BIGIP-bigip15.1...  2022-12-01T23...  2022-12-01T23...  Started tenant instance ce:1...
   2     2         Pending  BIGIP-bigip15.1...  2022-12-01T23...  2022-12-01T23...  Started tenant instance 22 5..

After you configure and deploy the tenant, and the Status is updated to Running, then you can use the management IP address to access the tenant system using SSH, the web-based Configuration utility, or TMOS Shell (tmsh).

Note: Once a tenant is Deployed (and is up and running), changing its state back to Configured or Provisioned stops the tenant. You will receive a warning message before this occurs.

Note: If the Status is Pending instead of Running, this might mean that there are not enough resources (vCPUs, memory, or other resources) for the tenant to be deployed. See the Tenant Details screen in the chassis partition webUI for more information about the specific tenant.

Configure DAG IPv6 prefix length from the CLI

You can configure the DAG IPv6 prefix length from the chassis partition CLI. DAG IPv6 prefix length is a configuration field on each tenant that is used by disaggregator algorithms as a networking mask. The valid configuration value is from 1 to 128. The default value is 128. You can configure the value from either the chassis partition or the tenant.

When you configure the value at the chassis partition level, it is pushed automatically to the tenant. When you configure the prefix length at the tenant level, future configuration at the chassis partition level is disabled and must be re-enabled from the tenant.

1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

   When you log in to the system, you are in user (operational) mode.

2. Change to config mode.

   config

   The CLI prompt changes to include (config).

3. Configure DAG IPv6 prefix length while creating a tenant.

   This propagates the value to the tenant. For more information, see Create and deploy tenants from the CLI.

4. Configure DAG IPv6 prefix length from the system after the tenant is created.

   This propagates the value to the tenant.

   tenants tenant <*tenant-name*> config dag-ipv6-prefix-length <value>

   This example changes the DAG IPv6 prefix length of a tenant named “velos-bigip” to 120.

   Copy

   default-1(config)# tenants tenant velos-bigip config dag-ipv6-prefix-length 120

5. Commit the configuration changes.

   commit

If you configure the DAG IPv6 prefix length, but the value is not propagated to the tenant, you might have previously configured this value externally (such as from the tenant’s webUI, CLI, or REST APIs). This disables configuration at the chassis partition level. On a BIG-IP tenant, run this command sequence to re-enable configuration:

tmsh mod sys db dag.userconfigipv6prefixlen value false

Display tenant information from the CLI

You can display detailed information about tenants configured in a chassis partition from the chassis partition CLI.

1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

   When you log in to the system, you are in user (operational) mode.

2. Show the tenants that are currently configured in a chassis partition.

   show tenants

   This example displays the operational data for a BIG-IP tenant spanning two blades. It uses one VLAN, no cryptos, two vCPU cores, and appliance mode is not enabled. The Instance table in the output displays the live health of the tenant running on the VELOS system.

   Copy

   default-1# show tenants tenant bigip
   tenants tenant bigip
    state unit-key-hash oa9gv8VYHcSoApv1234GQMn2uM9UzNKiDz78cIbqKv26LVjlIo9TCdp56z5UnXcVvr3hj0/ym2kbdWyBhPbkLA==
    state type          BIG-IP
    state image         BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
    state nodes         [ 1 ]
    state mgmt-ip       192.0.2.59
    state prefix-length 24
    state gateway       192.0.2.254
    state cryptos       enabled
    state vcpu-cores-per-node 2
    state memory        7680
    state storage size 76
    state running-state deployed
    state mac-data base-mac 00:94:a1:8e:70:0a
    state mac-data mac-pool-size 1
    state appliance-mode disabled
    state status        Running
    state primary-slot  1
    state image-version "BIG-IP 15.1.5 0.0.222"
    state instances instance 1
     instance-id   1
     phase         Running
     image-name    BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
     creation-time 2021-12-01T19:56:49Z
     ready-time    2021-12-01T19:56:35Z
     status        "Started tenant instance"
     mgmt-mac      f2:48:a7:f1:aa:ab

3. Show the running configuration of the tenants.

   show running-config tenants tenant

   A summary similar to this example displays:

   Copy

   default-1# show running-config tenants tenant
   tenants tenant bigip
    config type         BIG-IP
    config image        BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
    config nodes        [ 1 2 ]
    config mgmt-ip      192.0.2.59
    config prefix-length 24
    config gateway      192.0.2.254
    config cryptos      enabled
    config vcpu-cores-per-node 2
    config memory       7680
    config storage size 76
    config running-state deployed
    config appliance-mode disabled

Display tenant status and statistics from the CLI

You can monitor data and metrics related to the usage, performance, and behavior of a tenant from the CLI. These statistics, tenant CPU usage, memory usage, and disk usage, are crucial for monitoring, managing, and optimizing the tenant.

1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

   When you log in to the system, you are in user (operational) mode.

2. Change to config mode.

   config

   The CLI prompt changes to include (config).

3. Show ‌tenants status and statistics.

   tenants tenant <*tenant name*> state <*action*>

   This example displays the tenant status and statistics for a BIG-IP tenant running on the system.

   Note: You can get the stats with an average of 10 seconds, 30 seconds, 1 minute, 5 minutes, and 10 minutes.

   • For CPU stats:

     Copy

     default-1(config)# tenants tenant cbip state cpu-thread-stats average 1m-avg         
     averages {
             unix-seconds 1717588320
             cpu-threads {
                 cpu-thread {
                     thread-index 0
                     busy-percent 1
                 }
                 cpu-thread {
                     thread-index 1
                     busy-percent 0
                 }
                 cpu-thread {
                     thread-index 2
                     busy-percent 0
                 }
                 cpu-thread {
                     thread-index 3
                     busy-percent 4
                 }
                 cpu-thread {
                     thread-index 4
                     busy-percent 4
                 }
                 cpu-thread {
                     thread-index 5
                     busy-percent 4
                 }
                 cpu-thread {
                     thread-index 6
                     busy-percent 4
                 }
                 cpu-thread {
                     thread-index 7
                     busy-percent 12
                 }
                 cpu-thread {
                     thread-index 8
                     busy-percent 4
                 }
                 cpu-thread {
                     thread-index 9
                     busy-percent 1
                 }
                 cpu-thread {
                     thread-index 10
                     busy-percent 4
                 }
                 cpu-thread {
                     thread-index 11
                     busy-percent 4
                 }
                 cpu-thread {
                     thread-index 12
                     busy-percent 4
                 }
     default-1(config)#

   • For disk stats:

     Copy

     default-1(config)# tenants tenant cbip state disk-stats average 1m-avg
     averages {
             unix-seconds 1717588260
             used-percent 88
             disk-list {
                 disk {
                     disk-name nvme0n1
                     total-iops 0
                     read-iops 0
                     read-bytes 148
                     write-iops 154
                     write-bytes 1691163
                 }
             }
         }
     default-1(config)#

   • For interface stats:

     Copy

     default-1(config)# tenants tenant cbip state interface-stats average 1m-avg
     averages {
             unix-seconds 1717588380
             interface-list {
                 interface {
                     interface-name 1.0
                     ifc-bytes-in 1466
                     ifc-bytes-out 0
                     ifc-packets-in 0
                     ifc-packets-out 0
                 }
                 interface {
                     interface-name 2.0
                     ifc-bytes-in 135
                     ifc-bytes-out 0
                     ifc-packets-in 0
                     ifc-packets-out 0
                 }
             }
         }
     default-1(config)#

   • For memory stats:

     Copy

     default-1(config)# tenants tenant cbip state memory-stats average 1m-avg
     averages {
             unix-seconds 1717588440
             available 8493508881
             free 1060426615
             used-percent 93
             platform-total 16107667456
             platform-used 8114811835
         }
     default-1(config)#

Modify tenant configuration from the CLI

You can modify a tenant configured in a chassis partition from the chassis partition CLI.

The administrator is able to modify only these fields while the tenant is running:

• running-state
• vlans
• nodes

1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

   When you log in to the system, you are in user (operational) mode.

2. Show configuration information for the tenant you want to update.

   show tenants tenant <*name*>

3. Change to config mode.

   config

   The CLI prompt changes to include (config).

4. You can modify these options while the tenant is running: vlans, nodes, or running-state.

   tenants tenant <*name*> config { vlans <*vlan-id*> | nodes { 1 2 } | running-state { configured | provisioned | deployed } ]

5. To modify any of the other options, first change the running state of the tenant to provisioned.

   tenants tenant <*name*> config running-state provisioned

   Make desired changes. For more information, see the Tenant CLI command syntax section.

6. Commit the configuration changes.

   commit

Resize tenant virtual disk from the CLI

You can resize the storage quota for a tenant virtual disk from the chassis partition CLI.

1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

   When you log in to the system, you are in user (operational) mode.

2. Display configuration information for the tenant you want to update.

   show tenants tenant <*name*>

3. Change to config mode.

   config

   The CLI prompt changes to include (config).

4. Change the storage quota, in GB, for the virtual disk for a specified tenant.

   The default size is 77 GB.

   tenants tenant bigip-vm config storage size 80

   Note: You cannot modify the size of the virtual disk when the tenant is in the deployed running-state. The storage size can be modified only when the tenant is in a configured or provisioned running state.

5. Commit the configuration changes.

   commit

Delete a tenant from the CLI

You can delete tenant configurations in a chassis partition from the chassis partition CLI. It is recommended that you wait 5-10 minutes after deleting a tenant before deploying another tenant.

1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

   When you log in to the system, you are in user (operational) mode.

2. Show the tenants that are currently configured in that chassis partition to check the names of the tenants.

   show tenants

3. Change to config mode.

   config

   The CLI prompt changes to include (config).

4. Remove a tenant configuration from the chassis partition.

   no tenants tenant <*tenant-name*>

5. Commit the configuration changes.

   commit

The tenant deployment is removed from the chassis partition.

Tenant CLI command syntax

Use the tenants command from the chassis partition CLI to configure tenants on a chassis partition.

The tenant command includes this syntax and these options:

tenants tenant <*options*>

Tenant console overview

VELOS chassis partitions include a tenant console user that provides console access to tenants from the chassis partition’s management IP address.

Unlock the tenant console user from the CLI

The system creates the tenant console user account by default when you create a tenant, but the account is expired and has no password. Before you can access the tenant console, you must first unlock the tenant console user from the CLI.

1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

   When you log in to the system, you are in user (operational) mode.

2. Show information about configured users.

   show system aaa authentication users

   A summary similar to this example displays:

   Copy

   default-1# show system aaa authentication users
                LAST    TALLY  EXPIRY
   USERNAME     CHANGE  COUNT  DATE    ROLE
   ----------------------------------------------------
   admin        19370   0      -1      admin
   big-ip       0       0      1       tenant-console
   root         0       0      -1      root

   The expiration date for the tenant console user is 1, which indicates that the user account is locked. The admin and root accounts are enabled (-1), and there are no disabled (0) accounts.

3. Change to config mode.

   config

   The CLI prompt changes to include (config).

4. Set a password for the tenant console user.

   system aaa authentication users user <*tenant-name*> config set-password password

   This example sets a password for a specified tenant console user:

   Copy

   default-1(config)# system aaa authentication users user big-ip config set-password password
   Value for 'password' (<string>): *********

5. Set an expiration date for the tenant console user.

   system aaa authentication users user <*tenant-name*> config expiry-date -1

   This example enables the specified tenant console user:

   Copy

   default-1(config)# system aaa authentication users user big-ip config expiry-date -1

6. Commit the configuration changes.

   commit

7. Verify that the tenant console user is enabled and unlocked.

   show system aaa authentication users

   A summary similar to this example displays:

   Copy

   default-1# show system aaa authentication users
                LAST    TALLY  EXPIRY
   USERNAME     CHANGE  COUNT  DATE    ROLE
   ----------------------------------------------------
   admin        19370   0      -1      admin
   big-ip       19389   0      -1      tenant-console
   root         0       0      -1      root

Connect to a tenant instance console from the CLI

Before you can connect to a tenant console, your user account must have terminal access enabled. On BIG-IP tenants this is disabled by default.

The system creates the tenant-console user account by default when you create a tenant, but the account is expired and has no password. Before you can access the tenant console, you must first unlock the tenant-console user from the CLI.

1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

   When you log in to the system, you are in user (operational) mode.

2. View the instance identifier for a specified tenant on the chassis partition.

   show tenants tenant <*tenant-name*> state instances

   A summary similar to this example displays:

   Copy

   default-1# show tenants tenant big-ip state instances
   state instances instance 1 big-ip
    instance-id   1
    phase         Running
    creation-time 2023-01-31T12:30:28Z
    ready-time    2023-01-31T12:30:55Z
    status        "Started tenant instance"
    mgmt-mac      ca:c3:7d:64:30:7e

3. Connect using SSH to the tenant console, using the name of the tenant as the SSH username.

   ssh <*tenant-name*>@<*chassis-partition-ip*> -p 700<*instance-id*>

   In this example, you connect to a tenant named “big-ip” at a specified chassis partition IP address, where -p 7001 indicates the instance identifier for the tenant:

   Copy

   ssh big-ip@192.0.2.76 -p 7001

4. Log in to the tenant console.

   Note: The default login password is default.

   Copy

   jdoe@SEA-00012345:~$ ssh big-ip@192.0.2.76 -p 7001
   big-ip@192.0.2.76's password:
   Successfully connected to big-ip console. The escape sequence is ^]

5. Log in to the tenant using your configured credentials.

   Copy

   BIG-IP 17.1.0 Build 0.0.1599
   Kernel 3.10.0-862.14.4.el7.x86_64 on an x86_64
   big-ip login:

   If you are unable to log in, verify that your user has terminal access enabled. This is disabled by default on BIG-IP tenants.

Tenant high availability (HA) overview

You can configure tenants for high-availability (HA) on an VELOS system similar to how it is done on a BIG-IP system or for vCMP guests. To implement high-availability, you set up device service clustering or DSC. DSC provides synchronization and failover of BIG-IP configuration data and traffic groups on two or more tenants. The tenant administrator sets up DSC on the tenants.

For information on BIG-IP Next tenant configuration, see my.f5.com.

While you can set up HA for two tenants in two different chassis partitions on the same chassison the same system, it is not recommended. Mirroring is not supported on the same chassissystem. It is recommended that you set up HA for tenants in chassis partitions on two different chassison two different systems.

If you plan to set up mirroring, you must use an additional chassissystem. Connection mirroring requires that both VELOS systems have identical hardware platforms(chassis and blades). Also, each chassis within the Sync-Failover device group must contain the same number of blades in the same slot numbers.

Important: Tenants must have identical resources to ensure seamless HA failover. F5 does not support HA between tenants on disparate platforms.

For more information, see these guides at K000130285: F5 Product Manuals Index:

• vCMP for VIPRION Systems: Administration
• BIG-IP Device Service Clustering: Administration

Configure high availability (HA) for BIG-IP tenants

Before you begin, you must set up two VELOS systems with initial configuration, management IP addresses, gateways, DNS servers, and licensing. For more information, see VELOS Systems: Software Installation and Upgrade and other sections in this guide.

Note: For information about configuring high availability (HA) for BIG-IP Next tenants, see my.f5.com.

You can set up high availability for two BIG-IP tenants in chassis partitions that reside on two separate systems.

1. Log in to the chassis and create at least one chassis partition on both VELOS systems.

2. Log in to the chassis partition on each chassis and deploy a BIG-IP tenant.

   Note: Make sure that both tenants are running the same BIG-IP software version and that it is compatible with VELOS systems.

3. On the tenants, set up L2 network connectivity between the two tenants including setting up VLANs and self-IPs for ConfigSync, failover, and mirroring.

   For example, create the same VLAN on both tenants with management IP addresses that can communicate with each other.

4. Log in to each tenant and set the failover ConfigSync address to the self IP addresses on both sides.

5. Establish device trust: On one of the tenants, go to Device Management > Device Trust, create a device trust, and add the management IP of the other tenant.

6. Create a Sync-Failover device group: On the tenants, go to Device Management > Device Group and create a device group with the Group Type option set to Sync-Failover.

   For more information, see the “Working with Device Groups” section in BIG-IP Device Service Clustering: Administration at K000130285: F5 Product Manuals Index).

7. On the tenants, go to Device Management > Devices, select the device and initiate the first ConfigSync manually.

After setting up HA for tenants, you can optionally create traffic groups, enable mirroring on the virtual servers, and sync the configurations.

Understand that there are many ways to configure HA, and this summary explains the general work flow for how to approach tenant HA. Your environment might require additional steps.