Applies To:

Show Versions Show Versions

Manual Chapter: Understanding vCMP Guests
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

About vCMP guests

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, you can run up to sixteen guests simultaneously, depending 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.

Example illustration of guests running on a BIG-IP system Example illustration of guests running on a BIG- IP system
Important: In addition to other considerations, when considering whether to create a single slot or multi-slot guest, bear in mind that recovery from a blade hot swap is much more straightforward for multi-slot guests.

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.

Modifying the properties of a vCMP guest

You can use the BIG-IP Configuration utility to modify the properties of an existing vCMP guest.

  1. On the Main tab, click vCMP > Guest List.
  2. In the Name column, click the name of the vCMP guest that you want to modify.
  3. From the Properties list, select Advanced.
  4. Change the values of the properties you want to modify.
  5. Click Update.

Viewing the properties of a vCMP guest

You can use the BIG-IP Configuration utility to view the properties of vCMP guests.
  1. On the Main tab, click vCMP > Guest List.
  2. In the Name column, click the name of the vCMP guest that you want to view.
The system displays the properties of the guest.

Overview: Blade swap for a single-slot vCMP guest

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 its associated configuration objects. When you swap out the blade and redeploy the guest, the guest can resume traffic processing.

Disabling a vCMP guest

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.

  1. On the Main tab, click vCMP > Guest List.
  2. In the Name column, find the name of the vCMP guest that you want to disable.
  3. Select the check box to the left of the guest name.
  4. Click Disable. The BIG-IP system releases the resources dedicated to the guest.

Determine whether a slot is available for temporary migration

When you are preparing to migrate a guest, it's helpful to know on which slot the BIG-IP system will create the next guest. Knowing where the next guest will be created helps you make certain that the guest migrates to a slot other than the one you are preparing to swap.

Guest resource allocation sequence

The BIG-IP system uses a sequential pattern to determine the chassis slot and CPU cores to which single-slot guests deploy. You control to which slot your guest migrates by knowing this pattern and making sure that the slot to which you want the guest to deploy is the next open resource. You open a slot by disabling its guests; you fill a slot by deploying a temporary guest as placeholder. The table lists the order in which cores and slots are allocated to deploying guests.

Slot # CPU Cores 0 and 1 CPU Cores 2 and 3 CPU Cores 4 and 5 CPU Cores 6 and 7
Slot 1 Fills first Fills fifth Fills ninth Fills thirteenth
Slot 2 Fills second Fills sixth Fills tenth Fills fourteenth
Slot 3 Fills third Fills seventh Fills eleventh Fills fifteenth
Slot 4 Fills fourth Fills eighth Fills twelfth Fills sixteenth

Choose destination slot for migration

When you migrate your single-slot guest from a slot about to be hot swapped, you determine where that guest will migrate by analyzing the existing guest allocation and making sure that the next open resource is on a different slot.
  1. On the Main tab, click vCMP > Guest List.
  2. Analyze the vCMP guest allocation to determine on which slot the vCMP software will deploy the next guest.
  3. Your next step depends on the slot to which the vCMP software will deploy the next guest.
    If the next vCMP guest deploys on: Then you need to:
    a slot other than the slot on which it currently resides: No action is required. Perform the Migrating a single slot guest task.
    the slot on which it currently resides:
    • If you intend to swap out the blade in slot 1:
      1. Disable the single-slot guests on slot 1.
      2. Create temporary guests to fill slot 1, so that when you enable the real single slot guests, the host will migrate them to a slot other than slot 1.
      3. Migrate the guest.
    • If you intend to swap out a blade in a slot other than slot 1:
      1. Disable the single-slot guests on that slot.
      2. Disable a corresponding number of guests on slot 1, so that when you enable the real single slot guests, the host will migrate them to slot 1.
      3. Migrate the guest.

Creating a temporary guest

Before starting this task you should be logged in to the vCMP host using its management IP address, and in the process of migrating a single slot guest from a blade that is about to be hot swapped.
Creating a temporary guest is a useful technique when you need to control the slot to which the vCMP host will migrate a vCMP guest. The temporary guest consumes resources on the blade you are preparing to swap, so that when you migrate a guest, the vCMP host must migrate the guest to a different blade.
  1. On the Main tab, click vCMP > Guest List.
  2. Click Create.
  3. From the Properties list, select Basic.
  4. In the Name field, type a name for the guest.
  5. In the Host Name field, type the host name localhost.localdomain.
  6. In the Number of Slots list, retain the default value, Single Slot. This causes the guest to run on one slot only.
  7. From the Management Network list, select Bridged.
  8. For the Cluster IP Address setting, fill in the required information:
    1. In the IP Address field, type a unique management IP address that you want to assign to the guest. You use this IP address to access the guest when you want to manage a module running within the guest.
    2. In the Network Mask field, type the network mask for the cluster IP address.
    3. In the Management Route field, type a gateway address for the cluster IP address.
  9. From the Virtual Disk list, select the default value, None.
  10. Click Finish.
After you click Finished, the system creates a guest that consumes the next set of CPUs on the targeted slot.

Disabling a vCMP guest

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.

  1. On the Main tab, click vCMP > Guest List.
  2. In the Name column, find the name of the vCMP guest that you want to disable.
  3. Select the check box to the left of the guest name.
  4. Click Disable. The BIG-IP system releases the resources dedicated to the guest.

Migrating a single slot guest

For this task you must be logged in to the vCMP host using its management IP address, and you are in the process of migrating a single slot guest from a blade so that it can be hot swapped. Additionally, this task begins when you have either temporarily disabled guests or created dummy guests so that when you re-deploy the guest, it will migrate to the slot you intend.
When you re-deploy a guest that has been disabled (change its state from configured to deployed), the vCMP host migrates that guest to the next open set of available resources. Use this procedure to migrate the guest from the blade before you perform the hot swap, and then use this procedure again to migrate the guest back to the blade after the hot swap.
Important: Migrating a single slot guest to another slot is essential before performing a blade hot-swap if you want to preserve the BIG-IP configuration objects defined for that guest.
  1. Ensure that you are still logged in to the vCMP host using the BIG-IP system's cluster IP address.
  2. On the Main tab, click vCMP > Guest List.
  3. In the Name column, click the name of the vCMP guest that you want to deploy.
  4. From the Requested State list, select either Provisioned or Deployed.
  5. Click Update.
The guest migrates to the next available set of resources. It takes some time for the guest to boot and become accessible.

Hot swapping a VIPRION blade

You can hot swap a VIPRION blade when you need to replace it. Steps for performing a hot swap are platform dependent.
Refer to the appropriate platform guide for instructions on removing and replacing a blade on an active VIPRION chassis.
Option Description
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.
Once the new blade boots, the vCMP host adds it to the cluster, and you can migrate guests to it.

Migrating a single slot guest

For this task you must be logged in to the vCMP host using its management IP address, and you are in the process of migrating a single slot guest from a blade so that it can be hot swapped. Additionally, this task begins when you have either temporarily disabled guests or created dummy guests so that when you re-deploy the guest, it will migrate to the slot you intend.
When you re-deploy a guest that has been disabled (change its state from configured to deployed), the vCMP host migrates that guest to the next open set of available resources. Use this procedure to migrate the guest from the blade before you perform the hot swap, and then use this procedure again to migrate the guest back to the blade after the hot swap.
Important: Migrating a single slot guest to another slot is essential before performing a blade hot-swap if you want to preserve the BIG-IP configuration objects defined for that guest.
  1. Ensure that you are still logged in to the vCMP host using the BIG-IP system's cluster IP address.
  2. On the Main tab, click vCMP > Guest List.
  3. In the Name column, click the name of the vCMP guest that you want to deploy.
  4. From the Requested State list, select either Provisioned or Deployed.
  5. Click Update.
The guest migrates to the next available set of resources. It takes some time for the guest to boot and become accessible.

Overview: Blade swap for a multi-slot vCMP guest

When you swap out a blade that hosts a multi-slot vCMP guest, the configuration objects for that guest exist on the other blades, so they are automatically preserved through the swap process.

When a multi-slot guest sees a new blade active in the cluster, the vCMP system:

  • allocates a new virtual disk for the multi-slot guest on the new blade
  • deploys the guest
  • joins the guest to the vCMP virtual cluster of the multi-slot guest
  • copies the BIG-IP configuration that is active on the primary slot in the virtual cluster to the newly joined guest member
Important: If the initial-image specified in the guest configuration on the vCMP host is no longer physically available, then virtual disk creation on the newly inserted blade will fail because the vCMP system will not find the ISO image file it needs to create the virtual disk.

About software image selection and updates

When you create a multi-slot vCMP guest, you choose the ISO image to install for that guest. If you subsequently perform a hot swap on one of the blades on which that guest resides, that initial ISO image is used to recreate the guest.

A serious issue can arise if you have upgraded the BIG-IP software version in the interim between the initial install and the hot swap, but you have not changed the ISO image to correspond with the upgraded software.

To change the initial image for a guest, you need to edit that guest. To edit the guest you must first disable it.

Important: You may choose to not change the ISO image in cases where the upgrade is temporary (for example you might be trying out a specific software update to see if it addresses an issue, and after evaluating that update, you may well choose to go back to the prior software version). As long as the ISO image version of the other cluster members matches the version currently specified at the time you perform the hot swap, the guest will re-create successfully.

Disabling a vCMP guest

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.

  1. On the Main tab, click vCMP > Guest List.
  2. In the Name column, find the name of the vCMP guest that you want to disable.
  3. Select the check box to the left of the guest name.
  4. Click Disable. The BIG-IP system releases the resources dedicated to the guest.

Specifying the ISO image for a guest

The file that the vCMP host reads to re-create the virtual disk for a guest must reside in the host's /shared/images folder to be available as an Initial Image selection on the Guest List screen. If the file is not present, it may well be on the vCMP guest's /shared/images folder. If this is the case, you must copy that file to the proper folder on the host and wait for the host to validate it.

Before you start this task, you must have already disabled the vCMP guest so that you can edit its settings, and the necessary ISO file must be in place on the vCMP host.

When performing a BIG-IP software upgrade, you have the option of changing the ISO image version to match. Once you decide to keep that software version for processing traffic, you should change the ISO image version so that the vCMP host can recreate the virtual disk for the vCMP guest if one of the blades requires a hot swap.

  1. On the Main tab, click vCMP > Guest List.
  2. In the Name column, click the name of the vCMP guest that you want to modify.
  3. From the Properties list, select Advanced.
  4. From the Initial Image list, select the ISO image file for creating the guest's virtual disk that matches the other guests in the cluster.
  5. Click Update.
The ISO image needed to re-create the guest's virtual disk is now correctly set so that the impact of hot swapping a blade will have only a temporary impact.

Hot swapping a VIPRION blade

You can hot swap a VIPRION blade when you need to replace it. Steps for performing a hot swap are platform dependent.
Refer to the appropriate platform guide for instructions on removing and replacing a blade on an active VIPRION chassis.
Option Description
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.
Once the new blade boots, the vCMP host adds it to the cluster, and you can migrate guests to it.

About software image selection and live installation

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.

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 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. The BIG-IP system does not create virtual disks for a guest until you set that guest to the Provisioned state. If you move a guest from another state to the Configured state, the BIG-IP system does not delete the virtual disks previously attached to that guest. 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, then you can provision the BIG-IP modules within the guest.
Provisioned
When you move a vCMP guest to the Provisioned state, the system allocates resources (CPU, memory, network interfaces, and disk space) 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 reconfigure the properties of a guest after its initial deployment, the system immediately propagates some of those changes to all of that guest's VMs. 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.

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.

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.

About CPU cores allocation

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. The system selects 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.

BIG-IP system with CPU core allocations for guests BIG-IP system with CPU core allocations for guests

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.

About physical memory allocation

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

About virtual disks allocation

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.

The maximum size limit for a guest is 100GB, and the typical footprint of a new guest (when viewed from the host) is around 5GB.

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.

About hardware processors allocation

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 guests that you configure to run on a single slot, in the event of a reboot, the vcmp daemon migrates the guest to the next available allocation location.

vCMP guest modification considerations

Before modifying a vCMP guest, be aware of the following facts in regard to vCMP guest properties.

Property name Note
Host Name If the guest is in the Deployed state, the system immediately propagates the modification to all of the guest's VMs.
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: 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:
  • 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.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)