Manual Chapter : Tenant Management

Applies To:

Show Versions Show Versions

F5OS-C

  • 1.5.1, 1.5.0
Manual Chapter

Tenant Management

Tenants overview

A
tenant
is a guest system running software in a chassis partition (for example, a
BIG-IP
system). The
VELOS
system supports multi-tenancy: you can run several tenants in the same chassis partition. 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.
Specifications for
BIG-IP Next
tenants are available on the
F5
Beta portal.
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.
Tenants inherit certain capabilities, such as the license and VLANs, from the
chassis partition
. Do not try to install a new license or delete the existing license on the tenants.
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.

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.
VELOS Chassis
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)
T1-F5OS has limitations, so using the other images is recommended. Other images must be downloaded from the F5 downloads site.
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 the
F5
beta portal.

Tenant usage

This table lists general use cases for
BIG-IP
tenant images. Information about
BIG-IP Next
tenant images is available on the
F5
Beta portal.
Tenant image
Description of Use
ALL-F5OS
  • Use case: Need multi-tenancy, multi-module, and service chaining
  • Supports provisioning all VELOS-supported modules *
    (also called all-instance image)
  • Requires minimum 2 boot locations
  • Live-upgradable
*
See the VELOS data sheet for all currently-supported features.
T4-F5OS
  • Use case: Single tenant with multiple modules or Super-VIP scenario (virtual IP that spans multiple blades)
  • Supports provisioning all modules with increased capacity
  • Requires minimum 2 slots
  • Live-upgradable
T2-F5OS
  • Use case: Need maximum tenant density, maximum tenants per blade
  • Supports provisioning LTM or DNS only
  • Requires 2 slots
  • Live-upgradable
T1-F5OS
  • Use case: Need maximum tenant density, maximum tenants per blade
  • Supports lightweight LTM or DNS only (also called micro-instance)
  • Requires 1 slot
  • You cannot upgrade or apply a hotfix to the system

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 the
F5
Beta portal.
Tenant image
Disk size
Minimum memory
Minimum # vCPUs
Max tenants per blade
T1-F5OS
22 GB
4 GB
1
22
T2-F5OS
45 GB
8 GB
2
11
ALL-F5OS
77/82 GB
2
8 GB
2
9
T4-F5OS
142 GB
8 GB
2
4

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
    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
      .
    Depending on the image file size and network availability, the import might take a few minutes. 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).
    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 from 1-32 for the length of the prefix.
  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
    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.
  13. 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.
  14. 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.
  15. For
    Virtual Disk Size
    , specify the storage quota, in GB, for the tenant virtual disk.
    Default size depends on the image type used. The default size for the ALL image is 82GB.
  16. For
    State
    , choose one of these options:
    Options
    Description
    Configured
    The tenant configuration exists on the chassis partition, but the tenant is not running, and no hardware resources (CPU, memory) are allocated to it. This is the initial state and the default.
    Provisioned
    Moves the tenant into the Provisioned state, which causes the system to install the software, assign the tenant to nodes, and create virtual disks for the tenant on those nodes. If you choose this option, it takes a few minutes to complete the provisioning. The tenant does not run while in this state.
    Deployed
    Changes the tenant to the Deployed state. The tenant is set up, resources are allocated to the tenant, the image is moved onto the blade, the software is installed, and after those tasks are complete, the tenant is fully deployed and running. If you choose this option, it takes a few minutes to complete the deployment and bring up the system.
    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.
  17. 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.
  18. To restrict usage of the Bash shell for tenant administrators, set
    Appliance Mode
    to
    Enabled
    (this is
    Disabled
    by default.)
  19. 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.
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. A warning displays if you try to make any other changes.
  • Deployed
    : You can add or remove
    Allowed Slots
    or change the
    State
    only while tenants are running.
    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 except
    Image
    .
  • Configured
    : You can change all settings except
    Image
    .
  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, if in Configured state.
  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.
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.

Tenant management from the CLI

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:
    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
    >
    These options are available:
    Option
    Description
    appliance-mode
    Enable or disable root and Bash access for the tenant.
    cryptos
    Enable or disable crypto device support for the tenant.
    gateway
    User-specified gateway for the tenant management IP address.
    image
    User-specified image for tenant.
    memory
    User-specified memory in MBs for the tenant.
    mgmt-ip
    User-specified management IP address for tenant management access.
    name
    User-specified name for the tenant.
    nodes
    User-specified node numbers in the chassis partition to schedule the tenant.
    prefix-length
    User-specified prefix length for the tenant management IP address.
    running-state
    User-specified state for the tenant: configured, provisioned, or deployed.
    storage
    Storage quota for the tenant.
    type
    Tenant type. Options include
    BIG-IP
    and
    BIG-IP Next
    .
    vcpu-cores-per-node
    User-specified number of logical CPU cores for the tenant.
    vlans
    User-specified vlan-id from partition VLAN table for the tenant.
    This example creates a
    BIG-IP
    tenant named
    velos-bigip
    that spans two nodes and is in the Configured running state, by default:
    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 ]
  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.
    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:
    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 2021-12-01T19:56:49Z ready-time 2021-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 2021-12-01T19:56:50Z ready-time 2021-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:
    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.
    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:
    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... 2021-12-01T23... 2021-12-01T23... Started tenant instance ce:1... 2 2 Pending BIGIP-bigip15.1... 2021-12-01T23... 2021-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
).
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.
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.

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.
    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:
    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

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 76 GB, and the disk size range is from 22 GB to 700 GB.
    tenants tenant bigip-vm config storage size 80
    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 a cluster of virtual machines (VMs) that run on one or more nodes within a
VELOS
chassis partition.
The
tenant
command includes this syntax and these options:
tenants tenant <
options
>
Option
Value
Description
appliance-mode
enabled or disabled (default)
When enabled, appliance-mode disallows root and Bash access for the tenant.
cryptos
enabled or disabled (default)
Specifies the crypto device support for the tenant. When enabled, the tenant receives dedicated crypto devices proportional to the number of vCPU cores. When disabled, the tenant receives no crypto device support.
gateway
IP address
Specifies the IPv4 IPv6 address of the default gateway for the management network. This IP address can be changed on the tenant itself. This field is required.
image
Image name for the tenant
Specifies which software image to install on newly created virtual disks for this tenant. This field is required.
memory
Number of MB; 3840 MB is the minimum required per vCPU core or
min-memory = (3.5 * 1024 * vcpu-cores-per-node) + 512
Specifies the memory in MBs for the tenant. For the commit to succeed, tenant configuration requires the minimum MBs required depending on the number of cores specified for the tenant. For example, for 2 vCPU cores, the minimum amount of memory is 7680 MB. The administrator must decide the amount of dedicated memory needed to satisfy the requirements of the
BIG-IP
or
BIG-IP Next
modules that will be provisioned within the tenant.
The maximum amount of memory available per blade is 102400 MB.
mgmt-ip
IP address
Specifies the management IP address to the tenant. This address floats to the primary node of the tenant. The address can be changed on the tenant. This field is required.
name
Name of the tenant
Specifies the name of the tenant. This field is required.
nodes
Node numbers in square brackets separated by a space. For example, [1 2]
Lists the nodes that the tenant can be assigned to. This field is required. Specifies the nodes on the chassis partition on which to provision the tenant. Though you can specify nodes that are not part of the chassis partition, the tenant will not be provisioned until the resources are included in the chassis partition.
prefix-length
Decimal value
Specifies the prefix length of the management network. This field is required.
storage
Specifies the size of the tenant virtual disk. The default size is 76 GB. The disk size range is from 22 GB to 700 GB. The size of the virtual disk cannot be modified when the tenant is in the deployed running-state. The storage size can be modified when the tenant is in configured or provisioned running-states.
running-state
Configured (default), provisioned, or deployed
Specifies the state of a tenant: configured, provisioned, or deployed. Tenants are put in the configured state by default. Configured means the tenant exists on partition, but the tenant has no hardware resources (CPU or memory) allocated to it and it is not running. When the tenant is provisioned, the system assigns the tenant to nodes and creates virtual disks for the tenant on those nodes. In the deployed state, allocated resources are used to launch the tenant VM. Note that, specifying deployed causes the actions that occur in the configured and provisioned states. To shut down the tenant VM without removing the virtual disk, change the running state from deployed to provisioned. Changing the tenant running-state to configured from provisioned or deployed causes its virtual disk to be deleted.
storage
Storage quota in GB for the tenant (The default value is 76 GB)
Specifies how much storage quota a tenant is allocated. The range is from 22 to 700 GB.
type
BIG-IP
(default),
BIG-IP Next
, or other supported tenant type
Specifies the supported tenants on the VELOS system.
vcpu-cores-per-node
Decimal number (The default value is 2)
Specifies how many cores a tenant is allocated from each node that it is assigned to. Use tab completion to see a list of possible values on the current
VELOS
system.
vlans
VLAN ID
Specifies the VLAN ID to be used for tenant traffic. To process the traffic through the tenant, make sure the VLAN is configured on the chassis partition.

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 the
F5
Beta portal.
While you can set up HA for two tenants
in two different chassis partitions on the same chassis
, it is not recommended. Mirroring is not supported on the same
chassis
. It is recommended that you set up HA for tenants
in chassis partitions on two different chassis
.
If you plan to set up mirroring, you must use an additional
chassis
. 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
.
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 my.f5.com:
  • 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.
For information about configuring High Availability (HA) for
BIG-IP Next
tenants, see the
F5
Beta portal.
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.
    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 my.f5.com).
  7. On the tenants, go to
    Device Management
    Devices
    , select the device and initiate the first ConfigSync manually.
  8. For tenants on the r2000/r4000 platforms, configure MAC masquerade.
    For more information, see the "Managing Failover" section in
    BIG-IP Device Service Clustering: Administration
    at my.f5.com).
    For information about configuring MAC masquerade, see K13502: Configuring MAC masquerade (11.x - 16.x).
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.