frankdenneman.nl

ESX 4i support Jumbo Frames

by

Last week I blogged about jumbo frames being unsupported in ESX 4i.
Yesterday Charu Chaubal, Sr. Technical Marketing Architect at VMware blogged the following;

I am happy to say that this is merely an error in the documentation. In fact, ESXi 4.0 DOES support Jumbo Frames on VMkernel networking interfaces. The correction will hopefully appear in a new release of the documentation, but in the meantime, go ahead and configure Jumbo frames for your ESXi 4.0 hosts.

http://blogs.vmware.com/esxi/2009/12/esxi-40-supports-jumbo-frames.html
Although Jumbo frames being unsupported might not be an adopion blocker, this is quite good news for companies willing to use ESX 4i.

Impact of mismatch Guest OS type

by

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.

Upgrading to SRM 4 and SSL certificates

by

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.

Timekeeping best practices for Linux

by

VMware KB article 1006427 presents best practices for Linux timekeeping. These recommendations include specifics on the particular kernel command line options to use for the Linux operating system of interest. There is also a description of the recommended settings and usage for NTP time sync, configuration of VMware Tools time synchronization, and Virtual Hardware Clock configuration, to achieve best timekeeping results.
What surprised me is the recommendation done by VMware; “Note: In all cases use NTP instead of VMware Tools periodic time synchronization”
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427

VMworld 2009 sessions

by

After skipping both VMworld events in 2008 I’m attending the VMworld event in San Francisco. This is the first event after VMware released vSphere and I hope to see much in-depth information about the OS and it’s new features.  Duncan Epping  and Eric Sloof  posted info about interesting sessions, so I started browsing the session catalog as well.
The following sessions seems to be very interesting; [Read more…] about VMworld 2009 sessions