There are configuration issues that can have negative effects on the performance of your VMware environment and your DR operations.
It must be understood that the cumulative effect of having many of these small problems means major performance issues in your virtual environment. The good news is that these problems are easily identified with the right knowledge and tools and easily fixed once identified.
The sections below list common issues and tips for each of the main configuration areas.
Storage
The three most common storage configuration issues are described below: Too many LUNS per Array
Many types of storage are improperly configured as one large array. While this is the only available option for some iSCSI devices, this configuration will not scale well in disk I/O intensive environments.
In this configuration, you may find that your SAN becomes unusable from a practical standpoint long before you run out of storage space because a VM disk I/O will affect all other VMs.
For more information on LUN configuration in a VMware environment, please refer to VMware’s VMFS Technical Overview and Best Practices white paper.
Wasted Space
It is a common industry practice to over-allocate disk space to allow for data expansion. When planning, virtual administrators have to guess how much space to assign, with the primary consideration being “How much is more than enough?”
The reality is that a few of the VM’s will eventually use all of the space assigned, but most will not. All of these VMs contribute to WASTED SPACE and shorten the life of expensive storage devices.
Mis-aligned Volumes
VMFS partitions that are not aligned to 64kb boundaries suffer a performance decrease of approximately 7-12%. In addition, if you have VMs that are being replicated using block level replication techniques - and you properly align those VMs - you can reduce your replication bandwidth requirements by up to 50%. Incremental/differential space requirements can also be reduced by up to 50%.
Note If your partitions were created using the vSphere (ESX 4.0) client, then they should have been automatically aligned to the 64kb boundary.
For more details on partition alignment, see the VMware document “Recommendations for Aligning VMFS Partitions”.
Network
The two most common network configuration issues are described below: Understanding Default Load Balancing
The default load-balance configuration in VMware ESX is NOT statistical load balancing. Instead, it is a round-robin approach to load balancing which can lead to one NIC much more heavily used than the others.
The default option will not provide aggregate bandwidth to a single virtual machine. This will effectively function as active/passive with only 1 NIC being active. ESX supports alternative load-balancing methods such as 802.3ad link aggregation Broadcasts
Broadcasts can crush your ESX server performance even when the total amount of broadcasts is low in terms of bandwidth. This can be resolved by the proper allocation
of VLANs. When configuring your virtual network, make sure that server VMs are in VLANs that are isolated from user networks. User networks contain a large number of PC’s that issue a lot of broadcasts, which slow server performance because of interrupts.
Memory
The following memory configuration issues are commonly found in VMware environments.
Improper VM limits
A limit is a restriction on the VM, so it cannot use more memory than this limit. VMs often have limits set that are much lower than their RAM allocation. If the limit is set lower than the allocated memory value, the ballooning driver will start to inflate as soon as the VM demands more memory than this limit.
For more information on this topic, please see the blog article below:
http://www.vmguru.com/index.php/articles-mainmenu-62/mgmt-and-monitoring- mainmenu-68/96-memory-behavior-when-vm-limits-are-set
Low Amounts of Shared RAM
ESX servers scan pages of RAM periodically, searching for duplicate pages. When duplicate pages are found, the ESX server uses a single, read-only copy of the page in RAM and shares it among the VMs that have that page in common. If a VM attempts to change a shared memory page, a new read-write copy is created in RAM for that VM. The others continue to use the shared RAM as long as they have it in common.
Note that when an ESX server is booted, the common RAM is not instantly shared. The memory scanning process occurs at intervals over time - an overcommitted environment with a lot of shared RAM could still experience performance problems if multiple VMs are booted at the same time.
Using the same OS and patch revisions in your VMs can significantly increase the amount of shared RAM in your ESX environment. This, in turn, allows you to use more VMs with the available RAM in your environment.
CPU
The most common CPU configuration issues involve incorrectly configuring multiple vCPUs, which lead to a high % Ready value. This is described in more detail below.
Multiple vCPU VMs and % Ready
VMs don’t reside on a processor all of the time- they are scheduled on demand onto a processor. Note that a VM cannot be schedule to a processor until all of the cores required for that VM are available simultaneously. Mixing single, dual and quad vCPU VMs on the same ESX server will lead to an increase in CPU % Ready that will severely affect VM performance. A % Ready measurement should never exceed 4%, and even at that rating you may experience performance degradation.
To avoid this, reduce your VMs (where possible) to single vCPU VMs. If you have large amounts of VMs that require multiple vCPUs, separating these VMs onto their own clusters improves scheduling.
When performing P2V migrations, reduce low utilization servers to a single vCPU. To do this, you will have to:
• change the HAL (Windows) or kernel configuration (Linux)
• change this inside of the guest OS. Changing it at the VM setting level is not enough.
If there is a mismatch between the number of CPUs the guest OS thinks it has and the setting on the VM in vCenter, the VM will idle at high CPU utilization levels.
This section provides information on configuring vRanger and your deployment environment for the best performance.
This portion of the document contains the following sections:
Workload Protection Considerations...77 Space Saving Technologies...85 Filtering Catalog Collections...86 Integrating vRanger...89 vRanger and Tape Backup Vendors...89 Application Backup & Recovery: Recovery Manager for Exchange...97 Using vRanger and Microsoft PowerShell...98
This chapter outlines the hardware and software requirements for installing vRanger. This chapter contains the following sections:
Workload Protection Considerations...77 Configuring Backup Jobs...77 Configuring Replication Jobs...78 Load Balancing...84 Space Saving Technologies...85 Filtering Catalog Collections...86