BIG-IP Link Controller

BIG-IP PSM

BIG-IP WebAccelerator

BIG-IP WOM

BIG-IP Edge Gateway

Overview

A vCMP guest is an object that you create on the vCMP™ system
for the purpose of running an instance of one or more BIG-IP® modules. An
example of a guest is an instance of both BIG-IP®
Local Traffic Manager™ and BIG-IP®
Global Traffic Manager™. A guest has its own portion of system resources
allocated to it, such as CPU cores and disk space, effectively making the guest appear as if it
were a separate BIG-IP device. On a vCMP system, you can run up to sixteen guests simultaneously,
depending on licensing and type of hardware.

In addition to containing BIG-IP modules, each guest contains its own instance of TMOS®. This TMOS instance gives you the ability to provision, configure, and
manage each BIG-IP module within the guest.

This illustration shows three guests running on a BIG-IP system. Guest 1
runs on a single slot only. Guest 2 and Guest 3
each run on all available slots.

About software image selection and live installation

When you initially create a vCMP guest, you actively select the ISO image
to install for that guest. Then, when you move the guest to the Provisioned state, the vCMP host installs that ISO image onto each of the newly-created virtual disk images pertaining to that guest.

Important: The initial software image is used only when the system first creates the
virtual disk images. Subsequent software upgrades are done within the guest using the live
installation process.

About network modes for a vCMP guest

You can configure each vCMP guest to operate in one of two modes: Bridged or Isolated. The
mode you choose specifies whether the guest is bridged to or isolated from the vCMP host's
management network.

About the Bridged network mode

Bridged mode is the default network mode for a vCMP guest. This mode
provides full Layer 2 access between guests, and creates a bridge between each guest's
management interface, the host's management interface, and devices connected to the host's
front-panel management port. Typically, you configure a guest's management port to be on the
same IP network as the host's management port, with a gateway identical to the host's
management gateway. This allows you to make TCP connections (for
SSH, HTTP, and so on) easily from either the host or the external network to
the guest, or from the guest to the host or external network. Although the guest and the host
share the host's Ethernet connection, the guest appears as a separate device on the local
network, with its own MAC address and IP address.

About the Isolated network mode

Isolated mode isolates the guest from the management network. As in
Bridged mode, a guest in Isolated mode cannot communicate with other guests on the system.
Also, the only way that a guest can communicate with the vCMP host is through the console
port or through a self IP address on the guest that allows traffic through port 22.

Note: Although a guest in Isolated mode cannot communicate directly with the
management network, you can configure the guest to communicate to external networks
indirectly. You do this by configuring network routing or a firewall on the guest's
operating system.

About deployed guests and network modes

If the guest is already deployed:

Setting the network mode from Bridged to Isolated causes the vCMP host to remove all of
the guest's management interfaces from its bridged management network. This has the effect of
immediately disconnecting the guest's VMs from the physical management network.

Setting the network mode from Isolated to Bridged causes the vCMP host to dynamically add
the guest's management interfaces to the bridged management network. This immediately connects
all of the guest's VMs to the physical management network.

Changing this property while the guest is in the Configured or Provisioned state has no
immediate effect.

About vCMP guest states

A vCMP guest is always in one of these states:

Configured

This is the initial (and default) state for newly-created guests. In this state, the guest
is not running, and no resources are allocated to the guest. By default, when you create a
guest, the BIG-IP® system does not create virtual disks while the guest is
still in this state; instead, the system creates the virtual disks when you move a guest to the
Provisioned state. If you move a guest from another state to the Configured state, the BIG-IP
system does not delete any virtual disks previously attached to that guest. In this case, the
guest's virtual disks persist on the system. Other resources, however, such as CPU cores, are
automatically de-allocated. When the guest is in the Configured state, you cannot configure the
BIG-IP modules that are licensed to run within the guest; instead, you must first provision and
deploy the guest, and then provision the BIG-IP modules within the guest.

Provisioned

When you move a vCMP guest to the Provisioned state, the system allocates resources (CPU
cores, physical memory, and so on) to that guest. The system also creates virtual disks for the
guest and installs the selected ISO image on them. A guest does not run while in the
Provisioned state.

Deployed

After provisioning a guest, you deploy it. When deploying a guest for the first time, the
system installs an instance of the guest host on the guest's virtual disk. For guests in this
state, the BIG-IP system attempts to start and maintain a VM on each slot for which the guest
has resources allocated. If you have already deployed a guest, and you later reconfigure the
properties of that guest, the system immediately propagates some of those changes to all VMs of
that guest. The changes that the system immediately propagates are: Host name, cluster IP
Address (including network mask and management route), and the list of allowed VLANs.

About system resource allocation

The system resources that the BIG-IP® system allocates to each guest are:
CPU cores, physical memory, and virtual disk space. The system allocates resources to a guest
when you set the state of the guest to Provisioned.

CPU cores

For single-slot guests, when allocating CPU cores to a guest, the system determines the best
slot for the guest to run on, that is, the slot with the most unallocated CPU cores. For all-slot
guests, the system allocates CPU cores from every available slot.

The number of CPU cores that the BIG-IP system assigns to each guest depends on whether you
configure the guest to run on a single slot or on all available slots of the system:

Guest type

CPU core allocation

Single slot

The system allocates one or more CPU cores to the guest.

All slot

The system allocates two CPU cores from each available slot. For example, if three
slots are available, the system allocates two CPU cores from each slot, totaling six CPU
cores for that guest. The maximum number of CPU cores that the system can allocate to a guest
is eight.

This illustration shows that the BIG-IP system has allocated two CPU cores to guest1, which is deployed on slot 1. Note that guest0 has no CPU cores allocated to it because the guest has not yet been deployed.

Note the following:

You cannot directly configure CPU core allocation. CPU core allocation is always determined by whether you configure a guest to be a single-slot or all-slot guest, and by the number of slots available.

If an unavailable slot becomes available later, the system automatically re-allocates the CPU cores to each all-slot guest and to any single-slot guests previously allocated to this slot.

If rebooted for any reason, the BIG-IP system persists any single-slot guest to the same slot, thereby retaining the same CPU core allocation for that guest. However, if you change a guest's state at any time from Deployed to Configured, the BIG-IP system de-allocates the CPU cores for that guest.

Physical memory

The BIG-IP system allocates a portion of the total system memory to each guest.

Virtual disks

A virtual disk is a portion of the total disk space on the BIG-IP system that the
system allocates to a vCMP guest. The system allocates one virtual disk to each slot on which the
guest resides. Although each virtual disk for a guest has a fixed, maximum size limit, the actual
size of a virtual disk is the amount of space that the guest actually uses on that slot.

You cannot explicitly create virtual disks; instead, the BIG-IP system creates virtual disks
whenever you set the state of a guest to Provisioned and the guest does not already have an
attached virtual disk.

Hardware processors

On systems that include SSL and compression hardware processors, the vCMP feature shares these
hardware resources among all guests on the system.

About slot assignment and persistence

You
can configure a single vCMP guest to run on either one slot or all slots of the system:

If you configure a guest to run on a single slot only, the guest resides on one slot.

If you configure the guest to run on all slots of the system, the guest spans all available
slots. For example, if you configure a guest to span all slots of the system, and the system
contains three available slots, then the guest spans three slots. If a fourth slot becomes
available later, the guest then scales to span all four slots, thereby increasing the processing
power for that guest.

Important: For any guest that you configure to run on a single slot only, the BIG-IP® system ensures that, in the event of a reboot, the system persists the
guest to the same slot on which it ran prior to the reboot.

Note: You can view the specific slot assignments for a guest by accessing the vCMP
host and viewing the host properties.

vCMP guest modification considerations

Before modifying a vCMP guest, be aware of the following facts for these properties.

Property name

Note

Host Name

The system immediately propagates the modification to all VMs of the guest, if the
guest is in the Deployed state.

Cluster IP Address

The system immediately propagates the modification to all VMs of the guest, if the
guest is in the Deployed state.

Virtual Disk

If you change this value from a specific file name to None, the
BIG-IP® system detaches that virtual disk file from the guest. In this
case, the virtual disk remains on the system as an unattached virtual disk. If you want to
delete the virtual disk, you must do this explicitly, using the Virtual Disk List screen of
the BIG-IP Configuration utility.

Note: You can only modify the
Virtual Disk property by first changing the
State property to Configured.

VLAN List

The system immediately propagates the modification to all VMs of the guest, if the
guest is in the Deployed state.

State

If you change this value from Deployed or
Provisioned to Configured, the BIG-IP system
automatically de-allocates all resources except for the guest's virtual disk.

Management Network

If you change the value of the Network Mode property while the
guest is in the Deployed state, then:

Changing the mode from Bridged to Isolated causes the vCMP host to remove all of the
guest's management interfaces from its bridged management network. This has the effect of
immediately disconnecting the guest's VMs from the physical management network.

Changing the mode from Isolated to Bridged causes the vCMP host to dynamically add the
guest's management interfaces to the bridged management network. This immediately connects
all of the guest's VMs to the physical management network.

Changing the Network Mode property while the guest is in the
Configured or Provisioned state has no immediate effect.