分类：
2007-04-22 18:59:35
First, the configuration of the ESX host server must be scrutinized at both the physical hardware layer and the virtualization platform layer. The decisions in this area will affect the performance of every virtual machine hosted on the ESX server. The second area of performance optimization is at the virtual machine layer with the various virtual hardware configuration options and factors. The third and final area is the configuration of the guest operating systems running inside the virtual machines.
In this three-part article, we'll list twelve top tips that can boost the performance of your virtual environment in all three of these areas. We'll cover everything from upgrades to remote access to configuration tweaks. Are you ready? Let's get started.
Tip 1: Upgrade to VI3
If you are still running VMware ESX Server 2.x, you ought to know that the new VMware Virtual Infrastructure 3 (VI3) could bring significant performance improvements. That's not to mention major scalability, usability and hardware compatibility enhancements. Upgrading your ESX 2.x hosts and virtual machines to VI3 (using ESX 3.0.1) could bring performance improvements straight out of the box.
 |
||||
|
|
|||
|
||||
VMware has optimized several subcomponents of ESX Server in version 3. In particular, you can expect faster handling of page faults, context switches and memory management unit operations within virtual machines. Virtual machines can now use Physical Address Extensions (PAE) to access up to 16 GB, more than the previous limit of 3.6GB of RAM, without taking a severe performance hit.
Virtual networking within ESX 3.0 has been improved, both in the vmxnet virtual network adapter and in VM-to-VM networking. VMFS3 is a new version of the VMFS family of file systems that offers enhanced performance and scalability. Virtual machines are less dependent upon the Service Console, and their user-level virtualization components can now run on any available processor core. According to VMware, this also allows ESX 3.0 to scale up to 50% more virtual machines per host over ESX 2.5.
ESX 3.0 can use the ACPI power saving mode for better handling of idle virtual machines. Virtual machines can take advantage of up to four virtual processors. Other features in VI3 that also enhance performance and scalability are the distributed resource scheduler (DRS), resource pools, high availability (HA) and VMware Consolidated Backup. ESX 3.0 hosts can now support up to 20 physical network adapters.
If you do nothing else, look into upgrading to VI3. The difference is akin to jumping from Windows NT Server 4.0 to Windows Server 2003.
Tip 2: Improve your host's processor and memory
Your host server's physical hardware greatly affects the performance of all virtual machines that reside upon it. Processor and memory are two vital resources in this area.
Although VMware ESX Server is compatible with a broad range of server hardware, including older server equipment, a top-notch CPU and more memory will improve the performance of your guest environments. Always use the highest performing processors you can afford.
When making processor decisions, consider the amount of power draw each processor incurs as well as its heat output. Some processors are more efficient than others, and some processors that have massive brute strength may have hidden costs of more power consumption.
Also be aware that some processors actually can downgrade their performance on the fly when thermal thresholds are reached. Although this may sound like a great feature for increasing your processor's life expectancy, it will destroy the performance of your virtual machines. It is usually better to select a more efficient processor that will not have any thermal issues in your use case.
In addition to using high performance processors, having more processors is usually better. Most new processors are available in multi-core versions that increase processor density while maintaining physical server densities in the racks. VMware ESX Server supports many processor cores in both the 2.5 and 3.0 versions. Having more available processor resources will allow higher virtual machine densities on each physical host server and will increase the performance of existing virtual machines by reducing CPU contention.
It is also important to optimize the ratio of virtual machines to physical processor cores on the host server. More cores equal higher densities, in most cases. Running too many virtual machines per processor core will adversely affect performance. The optimal ratio depends on the resource needs and utilization of the individual virtual machines themselves. The DRS feature in VI3, along with resource pools, can help automate this part of the equation.
Add as much RAM as possible to your ESX hosts so long as it matches up to proper virtual machine densities that can be supported by the processors. VMware ESX Server hosts have a minimum of 8GB RAM; 16GB, 32GB or even 64GB are not uncommon.
When raw virtual machine performance is the most important metric, avoid over-committing memory. Although ESX can handle over-committed memory, it causes swapping to the virtual machine swap file located on disk. Disk is always slower than RAM, so avoid swapping to disk in order to enjoy the benefits of using physical memory.
Tip 3: Enhance your host's storage
This may sound obvious, but using the highest performing disk I/O subsystem possible will improve guest performance. If you plan on using local or direct-attached disk storage, use a RAID-5 array of Ultra320 SCSI or SAS disks. Many disk controllers support multiple channels, and splitting your disks across those channels will improve performance.
For example, if you have six SCSI disks and a two-channel controller, place three disks on each channel and configure them in a six-disk RAID-5 array, if possible, with your server hardware. Note that some servers' storage backplanes may not allow splitting the I/O in this manner.
You can install multiple disk controllers and additional disks in a host and use multiple file systems, placing some virtual machines on each of those file systems. This can be especially useful for partitioning virtual machines that are I/O intensive. For example, if you have twenty virtual machines on a host, and two of them are I/O intensive, you can add the additional controller and disks and either move the I/O intensive virtual machines onto the second controller or split all virtual machines across each controller, ensuring that only one I/O intensive virtual machine is allocated to each file system.
Just like in the physical world, if you need to improve disk seek time, put faster disks in the server. Use 15K RPM disks in the ESX host to improve the I/O performance for all of the virtual machines on that host.
Using a SAN will offload I/O operations from the ESX host server, which leaves more resources to the virtual machines. Depending on your situation, having more available bandwidth may also increase your I/O performance. Use a 4Gb Fibre Channel SAN infrastructure when possible.
Your virtual machines will inevitably share access to the ESX host server's I/O subsystem. You should use the I/O share allocation for each virtual machine to adjust the amount of I/O resources that the virtual machine should be given, as appropriate. For virtual machines that are not very I/O intensive, you can set resource shares to 500 (low), and for the more resource intensive virtual machines that require more priority to I/O resources, set their shares to 2000 (high).
Tip 4: Optimize your host's networking
When your physical server is running VMware ESX Server, you should use Gigabit Ethernet network adapters for improved networking performance. This means that you must have Gigabit switches as well. Gigabit network adapters allow more virtual machines to share each physical network adapter over Fast Ethernet and greatly improve network bandwidth for network intensive virtual machines.
When configuring your physical network adapters, the speed and duplex settings on each network adapter must match the speed and duplex setting used on the switch port to which it is connected. Having conflicting settings between the network adapter and the switch can be not only a performance problem but also a connectivity issue.
When using 100Mbit Fast Ethernet adapters, set the network adapter and switch port speed/duplex settings to 100/Full. When using Gigabit Ethernet, set the network adapter and switch port speed duplex settings to Auto Negotiate, which is usually the default setting.
You can increase the available network bandwidth and increase network fault tolerance by teaming multiple Gigabit network adapters into a bond. This can simplify the number of virtual switches mapped to physical network adapters as well. In order to take advantage of the Gigabit network adapters in your virtual machines, configure your virtual machines to use vmxnet or e1000 virtual network adapters and avoid vlance when possible.
In the next tip, we'll discuss VM-to-host placement, processors, unnecessary hardware and more.
Even though VMware ESX Server is known for high
performance, performance tweaks and a little know how can make it even
better. In this series, we are examining 12 tips for top-notch ESX
Server performance.
discussed VI3, host processors and memory, storage and host networking. Now we'll turn our attention to VM-to-host placement, remote access, virtual processors and memory and more.
Tip 5: Be aware of VM-to-host placement
Within an ESX 2.x environment, it is important to keep track of what is going on inside of the virtual machine. By distributing heavy load virtual machines on different hosts or by placing virtual machines that operate at different times throughout the day on the same host, you can increase performance of your virtual machines by reducing resource contention. This is a manual task when using VMware ESX Server 2.x.
Because virtual machines are easy to create and distribute, it's common to have a problem known as virtual machine sprawl. If it isn't managed properly, you can have unmanaged virtual machines out there that people forget about.
It's important to either shut down/power off or suspend unused virtual machines so that they aren't wasting valuable resources on the ESX Server. Even an idle virtual machine will chew up memory and processing power, taking it away from other virtual machines that could use it.
Upgrading to VI3 can help out with your VM-to-host placement problem. Rather than manually trying to figure out where a virtual machine best fits on which host server and with which other virtual machines, VI3's DRS and resource pool features will help do the job for you.
When deploying a virtual machine in VI3 with DRS, you no longer need to figure out which ESX Server is going to host the virtual machine. You simply assign the virtual machine to a resource pool. DRS will automatically move the virtual machine to the right ESX Server so that it can get the resources that it needs. DRS will automatically balance your virtual machines across all of the ESX Servers assigned to the resource pool, even after virtual machines are added, removed and modified.
If a virtual machine isn't getting enough resources, then DRS can automatically balance the virtual machine in the resource pool to ensure that all of the virtual machines are receiving enough resources. If a resource pool itself is running out of resources, additional resources can be added by simply adding additional ESX servers to the resource pool.
VI3's DRS feature requires VMotion capabilities to perform the automatic migrations. It can move virtual machines from one ESX Server to another without any downtime. It takes some of the guesswork out, and by doing so, virtual machine performance is optimized because the VM no longer has to deal with resource contention as it would if it were placed on an improper host server.
Tip 6: Use remote access carefully
Some virtual machine performance enhancements can be as simple as closing an unnecessary VMware Remote Console (VMRC) session. Although you might not think that this would cause a problem, every remote console session that is open is consuming valuable CPU resources in the service console.
You can improve performance of the virtual machine by simply not connecting through the remote console. The VMRC protocol is not optimized and was never designed to be used as a standard remote technology. Exceptions to this rule would be using the VMRC when KVM type access to the virtual machine is needed for doing occasional administrative functions or when console access is explicitly required.
To optimize performance, you should use third-party remote control software like the tools you use to remotely manage your physical servers. By using lighter-weight remoting technologies like the Citrix ICA client, Microsoft Terminal Services or Remote Desktop Protocol (RDP), Telnet or SSH, you can connect to your virtual machines without adversely consuming CPU resources from the ESX host's service console.
Keep in mind that not all guest-oriented remote access methods are created equally. As an example, some organizations use the Virtual Network Computing (VNC) viewer, and while it may consume more resources than some of the other viewers, it too is still a better choice than using the VMRC client.
Tip 7: Virtual machine processors and memory
In a physical environment, for better or worse, we are taught that increasing the number of processors or adding additional memory to a server increases the performance of the operating system and its applications. This same idea has migrated over to the virtualized environment. Unfortunately, multiple processors and sharing of memory will increase the load on your ESX server. And this is exactly what you are trying to eliminate.
If you notice slow performance on your virtual machine, examine its CPU usage. You should check to see how much idle time each processor has, and you should examine the overall system CPU utilization through the VMware Management Interface.
Adding additional processors to a virtual machine by using VMware's Virtual SMP is not always going to solve performance problems. Not all applications are able to take advantage of having multiple CPUs. Guest operating systems and applications should be analyzed to determine whether or not Virtual SMP would improve throughput.
If these applications are not multi-threaded or cannot use multiple processes in execution, adding Virtual SMP may consume valuable physical processor resources without actually offering the virtual machine any added performance benefit, and as a result, may take away resources from other virtual machines on the same physical host server.
Virtual SMP should be used sparingly. Running a virtual machine with a single virtual CPU will, in many cases, outperform the same virtual machine with Virtual SMP turned on. It is definitely a case-by-case scenario, and you should test each virtual machine environment.
If the slow performance is not caused by the CPU, examine the virtual machine's use of memory. It is important to determine if the guest operating system is paging or swapping memory. Since disk is slower than RAM, this bottleneck will need to be identified and corrected.
A number of tools and options are available to determine if paging is taking place. Within a Linux guest operating system, you can use the vmstat command. For a Windows guest operating system, use the Performance tool under Administrative Tools to check the value for pages/second. If a virtual machine has a high number of page faults, such as 1000 pages/second, increase its minimum amount of memory to eliminate the excessive paging taking place. If the minimum memory size is fast approaching the maximum memory size, then increase that resource setting.
Remember, you should allocate only as much memory to the virtual machine as is needed. Some due diligence and testing is needed here; giving a virtual machine additional memory will not always increase performance. In fact, that is a wasteful practice, because you are taking away valuable memory that could be allocated to an additional virtual machine or used to increase your virtual machine density on the host server.
Altering the virtual machine's minimum and maximum CPU resource allocation percentages is another way to affect performance. If you want to avoid CPU starvation for a virtual machine, set its minimum percentage to something other than zero. Conversely, to keep low priority virtual machines from consuming too many CPU cycles, you can set its maximum percentage to something lower, like 50%, thereby effectively throttling down that virtual machine and allowing other more pertinent virtual machines to make use of those valuable CPU cycles.
You can also control which physical processor or processors each virtual machine can use. This control is called processor affinity. The default setting is to use no affinity, and this is usually the best choice for most situations. You should only set a virtual machine's CPU affinity when absolutely necessary.
If you have a very resource intensive virtual machine running on a host server, you might want to set its CPU affinity to isolate that virtual machine and to protect its performance. Doing so will also protect the performance of all other virtual machines running on that same host server by changing each of their affinity settings to a different processor from that of the resource-intensive virtual machine.
Tip 8: Remove unneeded virtual hardware
In a physical server, it can be extremely difficult and time consuming to add/remove hardware components that are not constantly being used by the system. And typically, unused hardware devices on a physical server don't usually hinder system performance. This is not the case with a virtual machine.
Disabling or removing any virtual hardware components that are not being used by the virtual machine is a good way to increase a guest server's performance even if it is only by a very small amount. With a virtual machine, small performance boosts can make a world of difference across the entire host server.
If your virtual machine environment does not need a CD/DVD ROM drive, floppy drive, network adapter or COM and LPT ports, remove or disable them. If you later decide that your virtual machine needs one or all of these devices, virtualization makes it quick and easy to add them back at any time.
In the next part of this tip, we'll look at updating VMware tools, optimizing your guest operating systems and effectively using antivirus and backup tools.
Everyone can use a performance boost, and even an
enterprise-grade virtualization package like VMware ESX Server is no
exception. Careful tweaks can bring big performance gains for your
virtual environment.
In this series, we've discussed numerous ways in which you can boost your ESX Server environment's performance, ranging from storage to remote access to VM-to-host ratios. In this part, we'll look at updating your VMware tools, optimizing your guest operating systems and evaluating your antivirus tools and backup strategy.
Tip 9: Update VMware Tools
As you upgrade your ESX Server versions and/or install update patches, be sure to keep VMware Tools installed in your guest operating systems up-to-date. Sometimes, update patches may include fixes for components of VMware Tools, and in these cases, it is very important to update VMware Tools in your virtual machines.
If you migrate virtual machines from other VMware platforms
such as VMware Workstation or VMware Server, be sure to update VMware
Tools after migrating the virtual machine. There are differences in the
editions of VMware Tools between the different VMware products.
|
|
|
|
Be sure to enable the time synchronization between the ESX host and the virtual machine in VMware Tools. It is generally not a good idea to have multiple time synchronization schemes running concurrently; therefore you should not use other time synchronization tools such as NTP clients if you are using VMware Tools to perform the time sync.
If you must use an alternate time sync method, then disable the time sync in VMware Tools. This occurs commonly in Windows virtual machines that are members of an Active Directory because they must time sync with the domain controller.
For the best video display performance in Windows virtual machines, enable the hardware acceleration feature in Windows under the advanced graphics display settings on the Troubleshooting tab. This will smooth out the mouse when using Remote Console.
Tip 10: Optimize Windows guest operating systems
Defragmenting the contents of a virtual machine's virtual disk does have a positive effect on I/O performance. Using third-party server-based disk defragmentation tools such as Diskeeper or SpeedDisk will keep your disk structure organized.
Be careful not to schedule the defrag tasks during critical hours or have it run too frequently as this could unnecessarily consume too many resources at the wrong time. If your virtual machines are running with a REDO log, then ignore this tip. Never defrag a virtual hard disk with a REDO log file. Only defrag those disks which are in persistent mode.
You can free up some resources within a virtual machine by stopping and disabling unnecessary services and background tasks. When is the last time you needed Wireless Zero Configuration in your virtual machines?
Be careful not to disable a service that is needed by your applications that may not be obvious. If you are not sure if a particular service is needed, check with your system administrator or build a clone of the virtual machine that can be used to test the effects of disabling a particular service.
The following list contains a suggested subset of common Windows services that can usually be stopped and disabled in a virtual machine. Services should only be stopped and disabled when they are known to not be used or needed. This will vary between virtual machines, how they are being used and what applications are installed.
Uninstall Windows components that are never used. By doing this, you reduce the amount of memory consumed within the operating system, giving back memory to your apps as well as increase the security of your virtual machine.
Many virtual machines may never need the NTFS Last Accessed timestamp. By disabling this feature, you reduce the amount of non-obvious work that is being done behind the scenes and stealing valuable CPU resources. Do not confuse this timestamp with the Last Modified timestamp. The Last Accessed timestamp is recorded whenever the file is accessed (reads or writes). The Last Modified timestamp only records the date and time of the last write and is usually needed for backup and archiving purposes.
Many or all of your Windows virtual machines running on VMware ESX Server are likely servers. These servers usually do not require fancy graphic effects on the desktop, which unnecessarily slow down the virtual machine. Be sure to disable visual effects on all Windows virtual machines that do not have explicit enhanced graphical display requirements. Be sure to turn off showing each window's contents while dragging too.
In most cases, you won't need autumn leaves on your Windows servers' desktops either. Generally it is a good idea to disable desktop wallpaper. The only exception made in this case might be to use something like the , which is very useful for dynamically creating handy informational desktop wallpaper including system metrics such as the computer and domain names, disk free space and IP addresses. Microsoft recently acquired Sysinternals.
If you are running Windows XP in your virtual machines, you may want to disable the System Restore feature. Doing so will unlock disk space, CPU and I/O resources. You will not have the benefit of the restore feature in Windows XP, but you can just use VMware's Append Mode or Snapshot feature to compensate, which are generally more powerful anyway.
Some of the system power features, such as hibernation and hardware power management (turning off hard drives, monitor, etc.), do not have any real meaning in a virtual machine. It makes sense to disable these features in most cases. That goes for the screen saver, too. Don't worry; you won't cause any screen burn-in to your Remote Console!
You may argue that it can be useful to use screen savers on virtual machines to automatically lock the console after a specified period of time, but if you are having that problem, please re-read tip number 6. It is generally not a good idea to have console sessions open for extended periods of time. If you have interactive programs running, just close the remote console session without logging off. If you feel that you still have a security issue, then you may need to revisit your security design on your ESX servers.
Tip 11: Optimize Linux guest operating systems
When using Linux guest operating systems, choose a distribution with either a 2.4 kernel or a 2.6 kernel that can be recompiled with the number of ticks per second reduced to 100 from 1000. The default system clock of the Linux 2.6 kernel is 1000/second, which unnecessarily stresses the virtual hardware. The only way to change the behavior is to recompile the 2.6 kernel with this change. If you cannot recompile the kernel, use a Linux distribution with a 2.4 kernel instead. The 2.4 kernel uses 100 ticks per second by default.
It is very likely that your Linux virtual machines running on VMware ESX Server are servers themselves. Most Linux servers do not require X-Windows. When possible, do not install a graphical desktop -- just use the character-based console. Your Linux virtual machine will require much less resources.
If you do need a graphical desktop, then use a light-weight window manager such as WindowMaker. KDE and Gnome are both resource hogs and they will chew up more resources, impacting the potential performance of the virtual machine or using additional ESX host resources that could be used by other virtual machines.
When optimizing your Linux virtual machines, make sure that you disable or remove unnecessary daemons, services and background tasks. Remove any unneeded packages, too. This will free up processor and memory resources that can be redirected to your applications.
Tip 12: Use smart antivirus and backup configurations
If your virtual machines are not being used for production services, such as virtual machines used for testing and development purposes, you may not need to have an anti-virus solution installed (unless of course you are testing the anti-virus solution). Most production virtual machines will require an anti-virus solution.
You should configure your anti-virus solution optimally to maximize performance of your virtual machine. One of the first things you can do is set up scheduled virus scans to take place at off-peak hours so that the applications are not competing for resources with the anti-virus solution. In most cases, a single daily virus scan is adequate.
Servers usually do not need real-time virus scans, which can impact server performance. Disable the real-time virus scanning features when possible for production virtual machines, especially those used as database, file or Web servers. Most anti-virus solutions have the ability to exclude certain files, file types and directories.
Some application files do not need to be scanned and doing so will destroy performance, such as scanning a database's data files. Configure the anti-virus solution to exclude mission critical application files that are not a high risk of virus infection. Swap files may also be excluded in some cases.
If you are running a backup agent in your virtual machines, you should schedule the backups to take place during off-peak hours and not during a virus scan. Again, doing so will alleviate performance degradation from applications competing for resources with the backup solution.
And don't forget, as mentioned earlier, when you upgrade to VI3, take advantage of VMware Consolidated Backup feature when possible because it eliminates performance overhead within your virtual machines and on your network by offloading the backups onto your SAN. When combining VMware Consolidated Backup with one of many backup solutions on the market that take advantage of this new feature, a complete backup solution with zero network load and no overhead on the host server is possible, and it allows the virtual machines to then use all of the host server's resources to increase their own performance.
