A vCMP® guest is an object that you create on the vCMP system for the purpose of running one or more BIG-IP® modules. For example, a typical guest might run both BIG-IP Local Traffic Manager™ and BIG-IP Global Traffic Manager™. Each guest has its own portion of system resources (such as CPU cores and disk space) allocated to it, which makes the guest appear as if it were a separate BIG-IP device. On a vCMP system, the number of guests that you can run simultaneously, depends on licensing and hardware type.
In addition to running BIG-IP modules, each guest contains its own instance of TMOS®. This TMOS instance gives you the ability to provision, configure, and manage certain network components (such as self IP addresses) and any BIG-IP modules within the guest.
The 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.
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.
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.
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.
If the guest is already deployed:
Changing this property while the guest is in the Configured or Provisioned state has no immediate effect.
You can use the BIG-IP® Configuration utility to modify the properties of an existing vCMP® guest.
When you remove and replace blades, and want to preserve the existing configuration, you may need to migrate a guest. This is true when you need to swap all of the blades upon which your guest resides. On multiple slot guests, configuration information is stored on all blades, so when you remove a blade, the configuration is retained. But when you swap a single slot guest, or all slots of a multiple slot guest, you must take care to migrate the guest before you swap. This task guides you through the process of migrating your guest to another slot for the duration of the hot swap process and then migrating it back after the swap. Although this task preserves your guest and all of its settings, the easier (and preferable) method is to just save the BIG-IP® configuration objects configured on your guest (as a UCS file), create a new guest, and then import the UCS file to the new guest.
For more information on archiving and importing BIG-IP configuration objects, refer to the F5 Networks AskF5® Knowledge Base web site, http://support.f5.com.
When you swap out a blade that hosts a single slot vCMP® guest, migrate the guest to another slot before you swap out the blade to preserve the BIG-IP configuration objects through the swap process.
Migrating a single-slot guest to another slot copies the virtual disk and the configuration objects it contains. When you swap out the blade and redeploy the guest, the guest can resume traffic processing.
When you disable a guest, the BIG-IP® system deallocates its resources (such as CPU cores, physical memory, and virtual disks). Once disabled, you can edit the vCMP® guest, or you can migrate the guest to another slot and its resources are available for consumption by another guest.
|For VIPRION 2400 chassis||Refer to "Removing a blade" and "Installing a blade" in the Platform Guide: VIPRION 2400.|
|For VIPRION 4400 chassis||Refer to "Removing a blade" and "Installing a blade" in the Platform Guide: VIPRION 4400.|
When you initially create a vCMP® guest, you choose 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.
A vCMP® guest is always in one of these states:
When you set up and deploy multiple guests at once, there is good reason to move each guest first to the Provisioned state. This allows you to verify that the guest allocations are satisfactory before you commit the guests to full deployment. This allows you to confirm that the virtual disk installations are successful before deploying the guests. If there is a problem with one guest’s allocation or virtual disk installation, you might need to rearrange the resource allocations for your guests. Keeping the guests in the Provisioned state until you are confident in your allocations prevents you from having to shut down deployed guests to make these changes.
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.
For single-slot guests, when the system allocates CPU cores to a guest, the system determines the best slot for the guest to run on. From the slots identified on the Allowed Slots list, the system selects the slot with the most unallocated CPU cores. For all-slot guests, the system allocates CPU cores from the available slots (as defined by the Allowed Slots setting for this guest).
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:
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 and a dedicated chunk of memory to each slot on which the guest resides.
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.
Before modifying a vCMP® guest, be aware of the following facts in regard to vCMP guest properties.
|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: Guests in the Provisioned or Deployed state do not allow modification of this property. 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||Changing the value of the Network Mode property while the guest
is in the Deployed state, has consequences: