VMWare Server 2.0

Handy VMware guest compatibility documentation

The planning steps are incredibly important for a successful configuration of any VMware implementation, regardless of shape and size. One specific area you should consider while planning is supported guest operating system configuration limitations.

VMware frequently updates the Guest Operating System Installation Guide (GOSIG), an online book that gives specific information for VMware ESX Server, VMware GSX Server, VMware Server, VMware ACE, VMware Workstation and VMware Fusion guest operating systems. This guide gives very specific configuration matrices for the VMware product and the guest OSes that can be run within the product. Further, there are very handy known issues sections for each guest OS.

Supported VMware Server 2.0 configurations

A specific example that I have found this guide helpful in regards to VMware Server 2.0. According to the GOSIG resource, Windows Server 2003 is only a supported configuration on VMware Server 2.0 with Service Pack 1, Service Pack 2 or the R2 features added to Windows Server 2003. VMware ESX, however, has a fully supported configuration for Windows Server 2003, including the base release without any Service Packs or the R2 features, in all versions from 2.0 through 3.5 Update 3.

Supported Windows Server 2008 configurations

Some configurations are more obvious, such as running Windows Server 2008 as a guest operating system on a hypervisor that predates the release of the guest OS. In the GOSIG guide, Windows Server 2008 64-bit guest OSes are supported only on more current products. Some platforms, such as VMware GSX server and VMware ESX Server 2.x and 3.0x are not a supported configuration for this guest OS. Even with all of this information, and the officially supported configurations - you may find that certain situations are successful even though they are not listed in the GOSIG documentation. A better practice would be to match the hypervisors with the supported configurations in regards to the guest OSes, and this may mean standing up different versions of VMware products to cover the full range of OSes that are required in your environment.

Accessing VMware Server Web Access Logs for Authentication Failures

VMware Server 2.0 has a fundamentally different interface compared to the thick client that was used in the 1.0 product. Along with the different interface comes a logging mechanism for access to the web interface, VI Web Access. This is one of the key new display features of VMware Server 2.0. For more information on the look and feel of the new VI Web Access, be sure check out this SearchVMWare.com tip.

Simply put, VI Web Access is a purpose built web engine for access to the VMware Server configuration and console access. For both Windows and Linux hosts, there is one log file that is kept for the web interface. The file is kept at in the following locations by default:

Windows hosts: C:\Documents and Settings\All Users\Application Data\VMware\tomcat-logs
Linux hosts: /var/log/vmware/WebAccess

For my Linux installation, there is one log file, called proxy.log. The log file is relatively easy to read, however I recommend an enhanced text viewer such as NoteTab Light as there are many lines per server-side event in this log. The line below shows an authentication failure to VI Web Access:

[2008-10-23 00:13:34,523,http-8308-2,RequestProcessor] Error processing action request /action/login : [InvalidLogin] Login failed due to a bad username or password.

VI Web Access logging by default log only shows authentication issues, session timeouts, or other errors that occur. This log is separate from the other VMware Server logs, as they are generally separated by process. More information on the VMware Server product can be found in the online user’s guide.

Configuring VM automatic power-on in VMware Server 2

VMware Server 2.0 has quite a different interface than previous versions of the popular free hypervisor, and sometimes accessing familiar configurations becomes more difficult with a new interface.

One difference between the prior 1.0.x versions of VMware Server and the version 2 release is the virtual machine power-on settings.

In versions 1.0.x, the option to have a VM power on when VMware Server boots was a property of the VM itself. With version two, this property is actually a configuration value of the server. Further, there are a good number of additional options around VM startup order with VMware Server 2.

The first thing in configuring VM automatic power on is to go to the ‘Edit Virtual Machine Startup/Shutdown Settings’ configuration option link from the top page of the VMware Infrastructure (VI) Web Access. The figure below shows the area of the interface that this link is located:

In this area of VI Web Access, VMs can be configured to boot up automatically when the server powers on. One of the great new features of VMware Server 2 is that in this console, a sequence of VMs to be automatically started can be configured. This is important for many configurations where there are dependency services on one VM that provides something like DNS and DHCP on the network to the other systems.

In my VMware Server 2 implementation, there are two VMs configured to automatically start when the server powers on. Further, the startup delay can be configured for subsequent VMs. The figure below shows the VMware Server startup and shutdown options panel:

The move of this configuration to a server property instead of being per-VM is a good move for situations where VMware Server could carry more critical workloads. The added functionality around startup sequencing is also a welcome addition for better management options for the product.