♦ Avoid special characters and spaces in the display names of virtual machines. Create virtual machine display names with the same rules you apply when providing DNS hostnames.

♦ During a physical-to-virtual migration, adjust the size of the hard drives to prevent excess storage consumption of the target datastore.

♦ After a physical-to-virtual migration, reduce the amount of memory to a more appropriate level. In most physical server environments, the amount of RAM is drastically overallocated. In virtual environments, resource allocation must be carefully considered.

♦ After a physical-to-virtual migration, reduce the number of CPUs to one. Increase only as needed by the virtual machine. Additional virtual CPUs can cause unwanted contention with the scheduling of multiple vCPUs onto pCPUs. The number of vCPUs in a virtual machine should be less than the number of pCPUs in the server to prevent the virtual machine from consuming all pCPUs.

♦ Maintain virtual machine templates for several different operating system installations. For example, create and maintain templates for Windows Server 2003, Windows Server 2003 Service Pack 1, Windows Server 2003 Service Pack 2, Windows Server 2008, and so forth.

♦ When templates are brought online, place them onto isolated networks away from access by standard end users.

♦ Use CPU and memory reservations to guarantee resources to critical virtual machines and use share values to guarantee appropriate resources to critical virtual machines during periods of increased contention.

The configuration details regarding the virtual networking best practices shown here can be found in Chapter 10.

♦ Implement Microsoft Clustering Services to achieve high availability of individual virtual machines. Note that versions of ESX Server prior to 3.5 were certified for support of Microsoft server clusters in virtual machines. As of this writing, the recertification process for clustering in a virtual machine was not complete. Please refer to the VMware website for updated information about supported technologies.

♦ Implement VMware High Availability (HA) to provide automatic restart of virtual machines residing on an ESX Server that fails.

♦ Use strict admission control for HA clusters unless virtual machine performance is not as important as simply having the virtual machine powered on.

♦ Prioritize virtual machines for startup after server failure. Prepare a contingency plan for powering off unnecessary virtual machines in the event of server failure, resulting in reduced computing power.

♦ Implement a backup strategy that involves a blend of full virtual machine backups with file level backups.

♦ Purchase enough backup agents to ensure minimal recovery times for servers with critical production data. Schedule the backups to ensure that recovery times are appropriate for the data type. For example, for data with greater value and a requirement for quicker restore, backups should be scheduled more often than usual.

♦ Do not use virtual machine snapshots as long-term solutions to disaster recovery or business continuity. Snapshots are meant as a temporary means of providing an easy rollback feature and are used primarily for short term recovery purposes.

♦ Back up data as often as needed as determined by a written business continuity/disaster recovery plan. More critical data should be backed up more often to prevent less data loss in the event of disaster.

♦ Test the full and virtual machine backups regularly by restoring to a test or development network.

♦ Store a copy of virtual machine backups in an off-site location. Otherwise, use tools to perform virtual machine replication to distant datacenters. Virtualization offers significant advantages in the realm of disaster recovery because virtual machines are encapsulated into a discrete set of files.

♦ Purchase licenses for Windows Server 2003 Datacenter to achieve a greater return on investment and achieve less stringent VMotion restrictions. Datacenter licenses allow for the installation of an unlimited number of virtual machines per ESX Server host.

The following best practices will help you troubleshoot a problematic VI3 deployment.

♦ Monitor virtual machine performance with a combination of tools inside the virtual machine and tools in VI3. For example, use Task Manager inside of a virtual machine and the performance reports from VirtualCenter to monitor CPU utilization and to identify bottlenecks.

♦ Regularly review the levels of CPUReady and Ballooning in the performance charts provided by VirtualCenter. Abnormally high values of either counter would indicate an issue with CPU or memory, respectively.

♦ Create virtual machine benchmarks as a standard of comparison when changes are made.

♦ Create e-mail-based performance alarms for key virtual machines. Allow administrators to be notified of system problems for virtual machines that provide core network services such as mail, databases, and authentication.

♦ Identify the root of any problem, then attempt fixes based on monitoring results, feature dependencies, and the company's documented change management process. For example, if VMware HA is not failing over properly, review the DNS configuration for the affected hosts since HA relies on name resolution across ESX Server hosts.

♦ Engage in a systematic approach to identifying and fixing problems with ESX Server hosts and virtual machines.