♦ MAC Address Changes: Reject
♦ Forged Transmits: Reject
♦ Avoid VLAN tags used by common third-party hardware devices, like VLAN0. Virtual switches do not support the native VLAN as physical switches do.
♦ Define traffic shaping to reduce the outbound bandwidth available either to the virtual machines that do not require full access to the bandwidth of the physical adapter or to the virtual machines that inappropriately monopolize bandwidth. Weigh the options of micro-managing virtual machine bandwidth against the configuration of NIC teams with the installation of additional network adapters.
♦ Construct NIC teams on a physical adapter connected to separate bus architectures. For example, use one onboard network adapter in combination with an adapter from an expansion card. Do not use two adapters from the same expansion card in the same NIC team or two onboard adapters in the same NIC team.
♦ To eliminate a single point of failure at the physical switch, connect network adapters in a NIC team to separate physical switches that belong to the same broadcast domain.
♦ Consider creating a NIC team for the service console. Otherwise, consider providing multiple vswif ports on different networks for redundant Service Console access.
♦ Construct a dedicated Gigabit LAN for VMotion. Ideally, all physical network adapters in the server offer gigabit speeds.
♦ Create separate networks for test and production virtual machines.
Storage Management Best Practices
The configuration details regarding the virtual networking best practices shown here can be found in Chapter 4.
♦ When booting from SAN, mask each bootable LUN to be seen only by the ESX Server booting from that LUN.
♦ Build a dedicated and isolated storage network for iSCSI SAN storage to isolate and secure iSCSI storage-related traffic.
♦ Build a dedicated and isolated storage network for NAS/NFS storage to isolate and secure NAS/NFS storage-related traffic.
♦ Perform all masking at the storage device, not at the ESX Server host.
♦ Separate disk-intensive virtual machines on different LUNs carved from separate physical disks.
♦ Provide individual zoning configurations for each ESX Server host.
♦ Allow the SAN administrators to manage LUN sizes. VMFS extents might help immediate needs, but might lead to loss of data in the event that an extent becomes corrupted or damaged.
♦ Spread the storage communication workload across the available hardware devices. For example, if the ESX Server host has two fibre channel adapters, ensure that the VMkernel is not sending all traffic through one adapter while the other remains dormant.
♦ Use separate storage locations for test virtual machines and production virtual machines.
♦ Build LUNs in sizes that are easy to manage yet can host multiple virtual machines. For example create 300GB or 400GB LUNs to host 5 or 6 virtual machines. Be prepared to use storage VMotion to move disk intensive virtual machines.
♦ Use storage VMotion to eliminate down time when needing to migrate a virtual machine between datastores.
♦ Use Raw Device Mappings (RDMs) for Microsoft Clustering scenarios or to provide virtual machines with access to existing LUNs that contain data on NTFS formatted storage.
♦ Implement a solid change management practice for the deployment of new LUNs.Identify a standard sized LUN and stray from the standard only when the situation calls for it.
VirtualCenter Best Practices
The configuration details regarding the virtual networking best practices shown here can be found in Chapters 5 and 8.
♦ Uninstall IIS prior to installing VirtualCenter Server.
♦ Use the Service applet in the Windows Control Panel to configure the VMware VirtualCenter Server Service for autorestart.
♦ Design a strong high availability solution for the VirtualCenter database server (i.e., Microsoft Clustering or consistent database backups).
♦ To install VirtualCenter 2.5 with a SQL Server 2005 back-end database requires a SQL Server authenticated user account with membership in the db_owner database role and ownership of the VirtualCenter database. Once the installation of VC 2.5 is complete, the db_owner database role membership can (and should) be removed.
♦ Carefully monitor the transaction logs of the VirtualCenter database. To eliminate transaction log growth, configure SQL Server databases in Simple Recovery mode. For maximum recoverability, configure SQL Server database in Full Recovery mode.
♦ Configure VirtualCenter in an active/passive server cluster with Microsoft Clustering Services for high availability, or install VirtualCenter into a virtual machine and perform a copy of the virtual machine at regular intervals.
♦ Create a VirtualCenter hierarchy to support your management model. If your organization manages resources by location, then create management objects (datacenters, clusters, folders) based on location. On the other hand, if your organization manages by department, then create objects accordingly. In most organizations the VirtualCenter hierarchy will reflect a hybrid approach that combines location, department, server function, server type, and so forth.
♦ Apply the principle of least privilege to permissions assignment policies in VirtualCenter. Employees who use VirtualCenter as a common management tool should be granted only the permissions required to perform their job.
♦ Use Windows groups in the VirtualCenter security model. Assigning Windows groups to a VirtualCenter role that is assigned privileges and permissions will facilitate the application of similar settings in the future. For example, create a Windows group called DomainControllerAdmins that is a member of the VC role called DCAdmins, which has the privilege to power on and power off and has been granted the permission on a folder containing all domain controller virtual machines. When a new user is hired to administer the domain controller virtual machines, the user can simply be added to the DomainControllerAdmins Windows group and will inherit all the necessary permissions.
♦ Identify a systematic approach to LUN creation and management. Identify either the adaptive or the predictive scheme as the LUN management process. Keep in mind that your overall storage management may involve a combination of larger LUNs with several virtual machine files and smaller LUNs for individual virtual machine files.
♦ Configure DRS to perform VMotion based on comfort level. Some VMotion will be necessary to ensure balance and fairness of resource allocation.
♦ Disable the automated VMotion for critical virtual machines that you do not wish to be VMotion candidates based on the DRS algorithm.
♦ If the DRS algorithm suggests a VMotion migration of four or five stars, it is in the best interest of the system to apply the recommendation. The algorithm takes into account many factors for offering recommendations that result in increased system performance.
Virtual Machine Best Practices
The configuration details regarding the virtual networking best practices shown here can be found in Chapters 6 and 7.
♦ Construct virtual machines with separate drives for operating systems and user data. Place each of the virtual SCSI hard drives on separate virtual SCSI adapters.
♦ Always install VMware Tools to provide the optimized SCSI drivers, enhanced virtual NIC drives, and support for quiescing the file system during the VMware snapshot process.
♦ Use the VMware tools to complement the Windows Time Services to synchronize the time on a virtual machine. The Windows server functioning as the PDC emulator operations master should be configured to synchronize time with the same time server used by the ESX Server hosts.