Guest Requirements

Guest Processing Power

When you create a guest, you can specify the number of virtual CPUs that the guest can use, as well as the minimum amount of CPU processing power that is guaranteed to the guest for each virtual CPU. For the purposes of this discussion, the term “physical CPU” refers to a processing entity on which a software thread can be scheduled. A guest can be allocated up to four virtual CPUs (limited by the total number of physical CPUs on the VM Host system).

Integrity VM allows you to create a guest with more CPUs than the physical system has, issuing warning messages if there are not enough physical CPUs. When you create a guest, Integrity VM checks the current CPU resources and, if insufficient resources are available to run the guest in the current configuration, issues a warning but allows you to create the guest. This allows you to create guests for future configurations. However, the guest is not allowed to boot on a system that does not have enough physical CPUs. If you do not specify the number of virtual CPUs when you create the guest, the default is one virtual CPU.

You can also specify the minimum amount of processing power guaranteed to the guest from each virtual CPU. This is the guest's “entitlement.” When you create a guest, you can specify the entitlement as a percentage from 5% to 100%. If you do not specify the entitlement, the guest receives 5% entitlement by default. Alternatively, you can specify the entitlement as the number of CPU clock cycles per second to be guaranteed to each virtual CPU on the guest.

When the guest is booted, the VM Host ensures that sufficient processing power is available for each guest to receive its entitlement. For a guest with multiple virtual CPUs, it verifies that the guest entitlement is available on the same number of physical processors as the guest as virtual CPUs. The sum of the all the entitlements for all the running guests cannot total more than 100% for each physical processor. If insufficient CPU resources are available, the guest is not allowed to boot; error messages are displayed to indicate the specific problem.

If a guest is busy, and sufficient processing power is available on the system, that guest can receive more than its entitlement. When there is contention for processing power (as on an oversubscribed system with busy guests) each guest is limited to its entitlement. You can modify the number of virtual CPUs and entitlement for a guest, as described in “Changing Guest Configurations” in Chapter 5.

For guests with multiple virtual CPUs, the entitlement is guaranteed on all the virtual CPUs in the guest's configuration. To prevent contention, the VM Host schedules work across all the virtual CPUs in the guest's configuration.

Guest Memory Allocation

When you create a guest, you can specify the amount of virtual memory (in either gigabytes or megabytes) to be allocated to the guest. The amount of memory to allocate is the total of the following:

The amount you specify when you create the guest should be at least the total of these two amounts. If there is not enough memory in the current configuration, Integrity VM issues a warning but allows you to create the guest. This allows you to create guests for future configurations. When the guest is started, the VM Host makes sure that there is sufficient memory to run the guest. In addition to the amount of memory you specify for the guest, the VM Host requires a certain amount overhead for booting the guest. The amount of memory allocated to all the running guests cannot exceed the amount of physical memory minus the amount used by the VM Host for its operating system and its administrative functions. For more information about the memory requirements of the VM Host, refer to “Installation Requirements,” in Chapter 3.

Guest Virtual Networks

The guest virtual network consists of:

For the guest to communicate outside the VM Host system, each guest virtual network must be associated with a virtual switch (vswitch). If you start a guest without any vswitch, the guest has no network communication channel. This is like booting up a single system for the first time using the console.

For each network adapter accessible to a guest, you must create a vswitch. A vswitch functions like a physical network switch, accepting network traffic from one or more virtual machines and directing network traffic to an associated port. A vswitch can be associated with a VM Host physical network device, or it can be local to the virtual machines on the VM Host, providing a local network between guests.

You create a virtual switch using the hpvmnet command, as described in “Creating Virtual Switches” in Chapter 3. You can create virtual switches any time. If you create the guest before creating a specific vswitch, the guest is created and warning messages display the specific problem. This allows you to create guests for future configurations. In the examples in this manual, the vswitch is created before the guest.

You can also restrict physical network devices to use by the VM Host only.

Integrity VM always creates a vswitch named localnet. This network is not associated with a physical interface. It is used only for communication between the guests running on the same VM Host. This interface does not use a name server or router, and the VM host does not access the localnet.

The guest OS configures its own virtual network interface with an IP address using standard commands and utilities. It can also use DHCP.

Virtual Storage Devices

When you create a guest, you specify the virtual storage devices that the guest uses. Guest virtual storage devices are backed by physical devices on the VM Host system. You must have sufficient physical storage for the VM Host and for all of the guests.

When you create a guest with the hpvmcreate command, you can specify both the virtual devices that the guest recognizes and the physical backing stores on the VM Host system. The guest virtual storage devices are either disks or DVDs. Virtual disks are read/write, so they cannot be shared between guests or with the VM Host. Virtual DVDs can be specified as shareable, so they can be used as installation golden images. However, sharing DVDs among guests should be carefully planned to avoid poor performance and overly complex management.

When you allocate a storage device to guests, be careful not to cause conflicts in uses of a backing store. For example, if a file in a file system on /dev/dsk/c8t2d0 is used as a backing store, the raw device /dev/rdsk/v8t2d0 cannot also be used as a backing store. Conflicts are not always obvious, so it is important to be careful when allocating backing stores to guests. HP recommends that you create a matrix of all the VM Host's resources and the guests' usage of them. The worksheets presented in this chapter are helpful for organizing this information.

The physical devices on the VM Host system that can be used as backing stores are:

Integrity VM does not support HFS. NFS is supported but not recommended.

When you create the guest, Integrity VM checks the current physical configuration. If the guest uses backing stores that are not available, the guest is created and warning messages provide details. If you start a guest that requires physical resources that are not available on the VM Host system, the guest is not allowed to start, and error messages provide detailed information about the problem.

The physical backing store that you associate with a guest virtual device can affect the performance of the guest. Use the ioscan command to obtain information about the current device configuration on the VM Host system, and try to distribute the workload of the guests across the physical backing stores.

Each type of backing store type has benefits and drawbacks:

When you create logical volumes as backing stores, create them with no file system and do not mount them. Integrity VM uses them as raw devices.

Some devices should be restricted to use by the VM Host and to each guest. The VM Host requires restricted devices, as described in “Controlling Access to Devices” in Chapter 3. Guests also require dedicated storage devices for their guest operating system boot device and swap device.