During Healthchecks I frequently encounter virtual machines configured with the incorrect Guest OS type specified. Incorrect configuration of Guest OS of the virtual machine can lead to;

• Reduction of performance
• Different default type for the SCSI device *
• Different defaults of devices
• Wrong VMware Tools presented to the Guest OS resulting in failure to install
• Inability to select virtual hardware such as enhanced vmxnet, vmxnet3 or number of vCPUs.
• Inability to activate features such as CPU and Memory Hot Add.
• Inability to activate Fault Tolerance.
• VM burning up 100% of CPU when idling (rare occasions)

Buslogic SCSI Device
* Due to mismatch of Guest OS Type, windows 2000 and Windows 2003 can be configured with a Buslogic SCSI device. Using the Buslogic virtual adapter with Windows 2000 and 2003 will limit the effective IO queue depth of one. This limits disk throughput severely and lead to serious performance degradation. For more information visit KB article 1614

Virtual Machine Monitor and execution mode
Selecting the wrong Guest OS type can be of influence of the selected execution mode.
When a virtual machine is powering on, the VMM inspects the physical CPU’s features and the guest operating system type to determine the set of possible execution modes. This can have a slight impact on performance and in some extreme cases application crashes or BSODs.
VMware published a Must-Read whitepaper about the VMM and execution modes
http://www.vmware.com/files/pdf/software_hardware_tech_x86_virt.pdf

How to solve the mismatch?
vCenter only displays the configured Guest OS of the Virtual Machine, it will not check the installed operating system inside the virtual machine. Powercli offers the solution to this problem, today more and more people start to discover the beauty of Powercli and incorporate this in their day-to-day activities.

So I’ve asked PowerCLI guru Alan Renouf if he could write a PowerCLI script which can detect the Guest OS mismatch.

Get-View -ViewType VirtualMachine | Where { $_.Guest.GuestFullname} | Sort Name |Select-Object Name, @{N=”SelectedOS”;E={$_.Guest.GuestFullName}}, @{N=”InstalledOS”;E={$_.Summary.Config.GuestFullName}} | Out-GridView

Alans “one-liner” checks the configured Gues Os Type in the VM (VM properties) and queries the VMtools to see which operating system it reports.

Once the mismatch is identified, set the correct Guest OS Type in the VM properties as soon as possible. The best way to deal with the mismatch is to power-down the VM before changing the guest OS type.

I have a customer who wants to set memory reservation on a large scale. Instead of using resource pools they were thinking of setting reservations on VM level to get a guaranteed performance level for every VM. Due to memory management on different levels, using such a setting will not get the expected results. Setting aside the question if it’s smart to use memory reservation on ALL VM’s, it raises the question what kind of impact setting memory reservation has on the virtual infrastructure, how ESX memory management handles memory reservation and even more important; how a proper memory reservation can be set.

Read on…

My background is Fibre Channel and beginning 2009 I implemented a large iSCSI environment. The “other” storage protocol supported by VMware, NFS, is rather unknown to me. And to be honest I really tried to keep away from it as much as possible, thinking it was not a proper enterprise worthy solution. That changed this month as I was asked to perform a design review of an environment which relies completely of NFS storage. This customer decided to use IP-Hash as load-balancing policy for their NFS vSwitch, but what Impact does this have on the NFS environment?

Read on…

Recently I started to work on a project implementing SRM 4. One of the project requirements is to use SSL certificates issued by a trusted CA.  When upgrading to SRM 4, we ran into a small problem. Because of a change in the vCenter authentication protocol, a new certificate that complies with the new certificate content rules must be obtained.

The requirements changed of the “Subject Alternative Name”, the SSL certificate issued for SRM 1 environments use the FQDN of the vCenter server host. In SRM 4 environments, the Subject Alternative Name field must contain the FQDN of the SRM server.

This value will be different for each member of the SRM server pair. We installed the SRM server on a separate server, but If you have installed SRM on the vCenter server, then you do not need to acquire a new certificate.