Manual Chapter : Tenant Management

Applies To:

Show Versions Show Versions

F5OS

  • 1.0.0
Manual Chapter

Tenant Management

Tenant overview

A
tenant
is a guest system running software in a chassis partition (for example, a Classic BIG-IP system). 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 4096 MB minimum memory.
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 classic BIG-IP 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.

Tenants in a partition example

Here is a diagram of a VELOS CX410 chassis 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 the chassis partition is created, you can deploy individual tenants, and they 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. Green 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 images

Following are the four different Classic BIG-IP tenant images that you can deploy in VELOS partitions:
  • T1-VELOS: BIGIP-bigip1x.x.x-miro-1x.x.x.x-x.x.xxx.T2-VELOS.qcow2.zip.bundle
  • T2-VELOS: BIGIP-bigip1x.x.x-miro-1x.x.x.x-x.x.xxx.T1-VELOS.qcow2.zip.bundle
  • ALL-VELOS: BIGIP-bigip1x.x.x-miro-1x.x.x.x-x.x.xxx.ALL-VELOS.qcow2.zip.bundle
  • T4-VELOS: BIGIP-bigip1x.x.x-miro-1x.x.x.x-x.x.xxx.T4-VELOS.qcow2.zip.bundle
Each image type has different uses so you need to be sure to use the correct type for tenant needs. Here are the general use cases. Note that T1-VELOS has limitations so using the other images is recommended. Other images must be downloaded from the downloads site.
Tenant Usage
Tenant image
Description of Use
T1-VELOS
  • Use case: Need maximum tenant density, maximum tenants per blade
  • Supports lightweight LTM or GTM only (also called micro-instance)
  • Requires 1 slot
  • You cannot upgrade or apply a hotfix to the system
T2-VELOS
  • Use case: Need maximum tenant density, maximum tenants per blade
  • Supports provisioning LTM or GTM only
  • Requires 2 slots
  • Live-upgradable
ALL-VELOS
  • Use case: Need multi-tenancy, multi-module, and service chaining
  • Supports provisioning all modules (also called all-instance image)
  • Requires minimum 2 slots
  • Live-upgradable
T4-VELOS
  • Use case: Super-VIP scenario (virtual IP that spans multiple blades), single tenant with multiple modules
  • Supports provisioning all modules with increased capacity
  • Requires minimum 2 slots
  • Live-upgradable
Each of the images has different sizing requirements. You will need to understand the size of the 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.
Tenant sizing
Tenant image
Disk size
Minimum memory
Minimum # vCPUs
Max tenants per blade
T1-VELOS
22GB
4GB
1
22
T2-VELOS
45GB
8GB
2
11
ALL-VELOS
76GB
8GB
2
9
T4-VELOS
142GB
8GB
2
4

Tenant resource allocation considerations

Following are some of the 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.
  • The formula used for default memory allocation is:
    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.
Following 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

Use the following procedure to add or delete tenant images within a chassis partition. HTTPS must be used for 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 chassis partition webUI using an account with admin access.
  2. On the left, click
    TENANT MANAGEMENT
    Tenant Images
    .
  3. To add a tenant image, click
    Add
    .
    The Add Tenant Image popup screen displays.
  4. Add the image:
    1. Remote Host
      : Type the IP address of the remote image server.
      The remote host needs to be an HTTPS server with PUT/POST enabled and a valid CA signed certificate (not self-signed).
    2. Remote File Path
      : Type the path to the ISO image.
    3. Username
      : Type the user name for an account on the remote image server, if required.
    4. Password
      : Type the password for the account, if required.
    5. Click
      Add Image
      .
    Depending on the image file size and network availability, the import may 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
    .
Once you have added the tenant images you want to use to the chassis partition, you can create and deploy tenants that will use that software image. The tenant image has to be one that is listed as compatible with the VELOS system.

Deploy tenants from the webUI

Before you get started, import the tenant images 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. VLANs need to have been previously created 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 so on to assign to the tenant.
The partition administrator can deploy tenants from within a chassis partition.
  1. Log in to the 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
    , type a name for the tenant deployment.
    Only lowercase alphanumeric character and hyphens are allowed. Note that the name cannot begin with a number.
  5. Leave
    Type
    set to the default
    BIG-IP
    .
  6. For
    Image
    , select the software image that was previously imported onto the system.
    Ensure that the image you selected will meet your tenant deployment needs.
  7. For
    Allowed Slots
    , first select the appropriate option:
    • Partition Member Slots
      lists only slots that the chassis partition includes.
    • 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 allows you to preconfigure tenant deployments before the hardware is installed and before the partition is configured to include it.
    Then, select the slots (or blades) that you want the tenant to span from the list.
  8. For
    IP Address
    , type the IP address of the tenant.
  9. For
    Prefix Length
    , type a number from 1-32 for the length of the prefix.
  10. For
    Gateway
    , type the IP address of the gateway.
  11. For
    VLANs
    , select one or more VLANs that are available to the tenant.
    You cannot select a VLAN that is in use by another tenant. VLANs in use are shown in the list but cannot be selected.
  12. For
    Resource Provisioning
    , select either:
    • Recommended
      specifies recommended values for vCPUs and memory for the tenant.
    • Advanced
      allows 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 2 (1 vCPU is sufficient only for lightweight tenants). 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 to assign depends on the number of vCPUs assigned. The minimum amount memory needed is determined by the formula
    (3.5 * 1024 * #ofvCPUs) + 512
    ]. So the tenant needs a minimum of 7680 MB for 2 vCPUs, 14,848 for 4 vCPUs, and so on.
    If you do not allocate sufficient memory, you receive a warning message.
  15. For
    State
    , choose one of the following:
    • 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.
  16. If the tenant requires high-performance crypto processing and compression, for
    Crypto/Compression Acceleration
    , select
    Enabled
    .
    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.
  17. To restrict usage of the bash shell for tenant administrators, set
    Appliance Mode
    to
    Enabled
    . (Default is
    Disabled
    .)
  18. Click
    Save
    .
The tenant is configured, and when it is in the Deployed state, the tenant administrator can to log in to the tenant webUI or CLI using the management IP address (with HTTPS or SSH). You cannot log in to tenants in the Configured or Provisioned states.

Modify tenant deployments from the webUI

You can modify tenant deployment features such as slots, VLANS, and state information while the tenant is running.
  1. Log in to the 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. To update
    Slots
    , select the slots (or blades) that you want the tenant to span from the list.
  5. To update
    VLANs
    , select one or more VLANs that are available to the tenant.
    You cannot select a VLAN that is in use by another tenant.
  6. To change
    State
    , choose a different option than is currently selected:
    • Configured
      : the tenant is set up but the software is not yet installed, and the tenant is not able to start running.
    • Provisioned
      : the tenant is set up, resources are allocated to the tenant, the image is moved onto the blade, the software is installed, the virtual disk is created, but the tenant is not running. If you choose this option, it takes a few minutes to complete the provisioning.
    • Deployed
      : the tenant is set up, resources are allocated to the tenant, the image is moved onto the blade, the software is installed, the virtual disk is created, 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.
  7. Click
    Save
    .

Enable appliance mode on tenants

You can enable appliance mode for deployed tenants from the chassis partition webUI.
  1. Log in to the 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.

Configure HA for tenants

Before you begin, two VELOS systems need to be set up with initial configuration, floating addresses, management IP addresses, gateways, DNS servers, and licensing. (Refer to
VELOS Systems: Software Installation and Upgrade
and other sections in this guide for details.)
You can configure tenants for high-availability (HA) on a VELOS system similar to how it is done on a BIG-IP appliance, 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.
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 partitions on two different chassis.
If you plan to set up mirroring, it must use two chassis. Connection mirroring requires that both VELOS devices 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.
For detailed information, refer to these guides on support.f5.com:
Here we summarize a suggested process for setting up HA for two Classic BIG-IP tenants in chassis partitions that reside on two separate chassis.
  1. Log into the chassis and create at least one partition on both VELOS systems.
  2. Log into the partition on each chassis and deploy a classic 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 into 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
    (see
    BIG-IP Device Service Clustering: Administration
    ).
  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 workflow for how to approach tenant HA. Your environment may require additional steps.

Tenant management from the CLI

Import the tenant image from the CLI

Before you get started, you may want to place the tenant image you want to use on a local Linux server that uses HTTPS, so you can more easily import it to the VELOS chassis platform.
You can import a tenant image into a chassis partition using 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 mode.
  2. Import the tenant image to the partition.
    file import [port
    port-number
    ] username
    user
    password
    password
    remote-host
    IP-address or FQDN
    remote-file
    remote-file-path
    local-file
    local-file-path
    For example:
    file import username admin password Vx#28439 remote-host artifactory.company.com remote-file /tmp/BIGIP-bigip14.1.x-miro-14.1.2.8-0.0.496.ALL-VELOS.qcow2.zip.bundle local-file /var/import/staging/

Create and deploy tenants from the CLI

Before you get started, import the tenant images you want to use for the tenant deployments. You need to know into which partition you want to deploy the tenant. VLANs need to have been previously created 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 so on to assign to the tenant.
You can create and deploy tenants in a chassis partition.
  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 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>
    where
    <options>
    can be any of the following:
    Possible completions: 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 mgmt-ip. image User-specified image for tenant. memory User-specified memory in MBs for the tenant. mgmt-ip User-specified mgmt-ip for tenant management access. name User-specified name for the tenant. nodes User-specified node-numbers in the partition to schedule the tenant. prefix-length User-specified prefix-length for the tenant mgmt-ip. running-state User-specified state for the tenant: configured, provisioned, or deployed. type Tenant type. BIG-IP is the default value. 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 Classic BIG-IP tenant called
    mercury-vm
    that spans 4 nodes, and will be put into the configured running state, by default:
    tenants tenant mercury-vm config type BIG-IP image BIGIP-bigip14.1.x-miro-14.1.2.8-0.0.455.ALL-VELOS.qcow2.zip.bundle mgmt-ip 10.255.0.205 prefix-length 24 gateway 10.255.0.1 nodes [ 1 2 3 4 ]
  4. Commit the configuration changes.
    commit
  5. You can monitor the operational state of the tenant and move the tenant into the provisioned state, which causes the system to assign the tenant to nodes, and create virtual disks for the tenant on those nodes.
    tenants tenant mercury-vm config running-state provisioned
    When the system is creating the virtual disk and installing the image on disk, the operational state of the tenant shows this information:
    • PHASE – Allocating resources to the tenant is in progress
    • status – Provisioning
    partition1# show tenants tenant mercury-vm tenants tenant mercury-vm state name mercury-vm state type BIG-IP state mgmt-ip 10.255.0.205 state prefix-length 24 state gateway 10.255.0.1 state cryptos disabled state vcpu-cores-per-node 2 state memory 7680 state running-state deployed state mac-data mgmt-mac 00:0a:49:ff:20:0c state mac-data base-mac 00:0a:49:ff:20:0d state mac-data mac-pool-size 1 state appliance-mode disabled state status Provisioning INSTANCE NODE ID PHASE 1 1 Allocating resources to tenant is in progress ... 2 2 Allocating resources to tenant is in progress ... 3 3 Allocating resources to tenant is in progress ... 4 4 Allocating resources to tenant is in progress ...
    When the system completes the virtual disk creation, the operational state displays:
    • PHASE – Ready to deploy
    • status – Provisioned
    partition1# show tenants tenant mercury-vm tenants tenant mercury-vm state name mercury-vm state type BIG-IP state mgmt-ip 10.255.0.205 state prefix-length 24 state gateway 10.255.0.1 state cryptos disabled state vcpu-cores-per-node 2 state memory 7680 state running-state deployed state mac-data mgmt-mac 00:0a:49:ff:20:0c state mac-data base-mac 00:0a:49:ff:20:0d state mac-data mac-pool-size 1 state appliance-mode disabled state status Provisioned INSTANCE NODE ID PHASE --------------------------------- 1 1 Ready to deploy ... 2 2 Ready to deploy ... 3 3 Ready to deploy ... 4 4 Ready to deploy ...
  6. You can then deploy the tenant.
    tenants tenant mercury-vm 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 that the tenant is assigned to.
  7. Commit the configuration changes.
    commit
  8. You can check the status of the tenant.
    show tenants tenant mercury-vm state instances
    INSTANCE NODE ID PHASE IMAGE NAME ... STATUS -------------------------------------------------------------------- 1 1 Running BIGIP-bigip14.1.... Started tenant instance 2 2 Running BIGIP-bigip14.1.... Started tenant instance
  9. Return to user mode.
    end
Once you configure and deploy the tenant, you can use the management IP address to access the BIG-IP system using SSH, webUI, and TMOS Shell (
tmsh
).

Tenant CLI command syntax

Use the
tenants
command to configure a cluster of virtual machines (VMs) that run on one or more nodes within a VELOS chassis partition.
The
tenant
command has the following syntax:
tenants tenant <options>
Where these are the options:
Option
Value
Description
appliance-mode
enabled or disabled (default is disabled)
When enabled, appliance-mode disallows root and bash access for the tenant.
cryptos
enabled or disabled (default is disabled)
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 IP 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
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 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]
This list contains 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 partition.
prefix-length
Decimal value
Specifies the prefix length of the management network. This field is required.
running-state
Configured, provisioned, or deployed (default is configured)
Specify 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.
type
BIG-IP (default) or other supported tenant type
Supported tenants on the VELOS system. The field is not required.
vcpu-cores-per-node
Decimal number (default is 2)
This value 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 partition.

Display tenant information from the CLI

You can display detailed information about tenants configured in a chassis partition by logging into 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 mode.
  2. Show the tenants that are currently configured in that chassis partition.
    show tenants tenant options: state primary-slot <name> state instances
    The following CLI command shows the operational data for a Classic BIG-IP tenant spanning two blades. It uses one VLAN, no cryptos, two vCPU cores, and appliance mode is not enabled.
    partition1# show tenants tenants tenant velos-bigip state name velos-bigip state type BIG-IP state mgmt-ip 10.255.0.59 state prefix-length 24 state gateway 10.255.0.1 state vlans [ 200 ] state cryptos disabled state vcpu-cores-per-node 2 state memory 7680 state running-state deployed state mac-data mgmt-mac 00:0a:49:ff:20:09 state mac-data base-mac 00:0a:49:ff:20:0a state mac-data mac-pool-size 1 state appliance-mode disabled state status Running state primary-slot 1 state image-version "BIG-IP 14.1.3.1 0.0.155" NDI MAC ---------------------------- default 00:0a:49:ff:20:0b INSTANCE NODE ID PHASE IMAGE NAME ---------------------------------------------------------------------------------------- 1 1 Running BIGIP-bigip14.1.x-miro-14.1.3.1-0.0.155.ALL-VELOS.qcow2.zip.bundle 2020-09-15T06:15:41Z 2020-09-15T06:15:58Z Started tenant instance 2 2 Running BIGIP-bigip14.1.x-miro-14.1.3.1-0.0.155.ALL-VELOS.qcow2.zip.bundle 2020-09-15T06:18:20Z 2020-09-15T06:18:18Z Started tenant instance partition1#
    The Instance table in the output displays the live health of the tenant running on the VELOS system.
  3. You can also show the running configuration of the tenants.
    show running-config tenants tenant

Update tenants from the CLI

You can update a tenant configured in a chassis partition.
  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 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. You can modify these options while the tenant is running:
    vlans
    ,
    nodes
    , or
    running-state
    .
    tenants tenant <name> config options: vlans nodes running-state
    tenants tenant <name> config vlans <vlan-id> tenants tenant <name> config nodes [1 2] tenants tenant <name> config running-state [configured|provisioned|deployed]
    Make desired changes.
  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. Refer to
    Tenant CLI command syntax
    for details.
  6. Commit the configuration changes.
    commit

Delete a tenant from the CLI

You can delete tenant configurations from the chassis partition using 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 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.