Set VMware VUM to use HTTP download

VMware vCenter Update Manager (VUM) comes preconfigured with a couple of download locations to download your ESX(i) patches. By default VUM uses HTTPS to connect to the download locations. This is secure, but some companies want to know what you download and / or scan everything that you download. Therefore they request you to download your patches using HTTP.

To configure VUM to use HTTP in stead of HTTPS you’ll need to edit the following XML file (please create a copy before manually editing the file) :

<install location VUM>\VMware\Infrastructure\Update Manager\vci-integrity.xml

This file contains the host configuration settings for VUM. Change the following entries from https to http.

<ESX3xUpdateUrl>https://www.vmware.com/PatchManagementSystem/patchmanagement
</ESX3xUpdateUrl>

<ESX4xUpdateUrl>https://hostupdate.vmware.com/software/VUM/PRODUCTION/index.xml
</ESX4xUpdateUrl>

<ESXThirdPartyUpdateUrl>https://hostupdate.vmware.com/software/VUM/PRODUCTION/csco-main-index.xml</ESXThirdPartyUpdateUrl>

After you have saved the file vci-integrity.xml restart the VUM service on the server where VUM is installed.

VMware still leader in x86 Infrastructure Virtualization

Gartner published their magic quadrant again for x86 Server Virtualization Infrastructure. VMware again came out as the number 1 company in infrastructure virtualization.

The number of installed server VMs and containers has nearly doubled in the past year as competition improves, virtualization adoption expands, the midmarket heats up, desktop virtualization drives more workloads to servers and workloads are deployed by cloud computing providers.

The magic quadrant by Gartner shows VMware being the number 1 company in x86 Infrastructure Virtualization, followed by Microsoft and Citrix .

As of mid-2011, at least 40% of x86 architecture workloads have been virtualized on servers; furthermore, the installed base is expected to grow five-fold from 2010 through 2015 (as both the number of workloads in the marketplace grow and as penetration grows to more than 75%). A rapidly growing number of midmarket enterprises are virtualizing for the first time, and have several strong alternatives from which to choose. Virtual machine (VM) and operating system (OS) software container technologies are being used as the foundational elements for infrastructure-as-a-service (IaaS) cloud computing offerings and for private cloud deployments. x86 server virtualization infrastructure is not a commodity market. While migration from one technology to another is certainly possible, the earlier that choice is made, the better, in terms of cost, skills and processes. Although virtualization can offer an immediate and tactical return on investment (ROI), virtualization is an extremely strategic foundation for infrastructure modernization, improving the speed and quality of IT services, and migrating to hybrid and public cloud computing.

For the entire article go to the Gartner post over here.

Unattended install of VMware Tools

Large environments require different techniques in rolling out software packages. This is also the case for VMware Tools.

You can of course right click on the virtual machine in the vSphere Client and select Guest > Install/Upgrade VMware Tools or even create a PowerCLI script to do the job for you. But sometimes, and common in large environments, you need to comply with the IT infrastructure policy and install your VMware Tools by using a software distribution tool like Microsoft System Center Configuration Manager.

For this you need to know how the VMware Tools MSI package is installed and which options you want to install. For this Valentin Hamburger, Technical Account Manager @ VMware, has written a great PDF document containing the decomposition of the VMware Tools package.

The picture below shows the various installation options from the VMware Tools MSI package and if they are required or not.

You can download the complete PDF over here, but with the following disclaimer : “This documentation is provided “as is”. It is not part of the official VMware product documentation.”

ESXi Scratch Partition

Not something you will be dealing with during normal day-to-day vSphere operations, but you can bump into problems if you don’t have a scratch partition.

This happened to me while upgrading some ESXi host with VMware Update Manager, but can also happen when you are trying to generate log files for VMware Support. And what’s more annoying then having system log generation problems when trying to deal with another error in your vSphere environment.

What is the ESXi scratch partition?

The scratch partion is a 4 GB VFAT partition that is created on a target device that has sufficient space available and is considered “Local” by ESXi.

The scratch partition is used for a couple of things:

* Store vm-support output (if scratch partition is unavailable the output will be stored in memory)
* During first boot the partition will be configured through syslog for retaining logfiles
* Userworld swapfile (when enabled)

The scratch partition is created and configured during ESXi installation or the autoconfiguration phase when the ESXi server first boots.

ESXi selects one of these scratch locations during startup in order of preference:

1. The location configured in the /etc/vmware/locker.conf configuration file, set by the ScratchConfig.ConfiguredScratchLocation configuration option
2. A Fat16 filesystem of at least 4 GB on the Local Boot device.
3. A Fat16 filesystem of at least 4 GB on a Local device.
4. A VMFS Datastore on a Local device, in a .locker/ directory.
5. A ramdisk at /tmp/scratch/

There are two examples where scratch space may not be automatically defined on persistent storage. In each case, the temporary scratch location will be configured on a ramdisk.

1. ESXi deployed on a Flash or SD device, including a USB key. Scratch partitions are not created on Flash or SD storage devices even if connected during install, due to the potentially limited read/write cycles available.
2. ESXi deployed in a Boot from SAN configuration or to a SAS device. A Boot from SAN or SAS LUN is considered Remote, and could potentially be shared among multiple ESXi hosts. Remote devices are not used for scratch to avoid collisions between multiple ESXi hosts.

So for the record, a scratch partition isn’t always created, and even isn’t required to run ESXi, but it can result in strange problems during vSphere operations. So better be safe, then sorry and create your scratch partition in advance.

Always have a scratch partition

The reason for this article is the fact that I ran into trouble while updating my ESXi host with VMware Update Manager. This was due to the fact that my servers had SAS disks and no scratch partition was configured. This led to this VMware KB article which explained how to configure your scratch partition by setting the advanced option ScratchConfig.ConfiguredScratchLocation.

This solved my problem and I’ve made it a best practice to configure my scratch partition, by setting ScratchConfig.ConfiguredScratchLocation, in my kickstart script. The scratch partition is to be located on the local VMFS datastore of my server. After all ESXi creates this local VMFS datastore from the disk space that isn’t used (when dealing with servers with local disks). This remaining disk space is more then enough to host the scratch partition. This way the scratch partition persistent and is always created, even in the case of local SAS disks.

For more information, and the sources of all my information for this article, have look at the following links:

About the Scratch Partition – page 56 – ESXi Installable and vCenter Server Setup Guide

VMware KB article 1033696 : Creating a persistent scratch location for ESXi

VMware KB article 1014953 : Identifying disks when working with VMware ESX

VMware ESXi Chronicles : Ops changes part 5 – Scratch Partition

Bug: Host Profiles forgets AD OU structure

Lately I’ve been playing around with VMware vSphere Host Profiles. This feature creates baseline configurations for your ESX / ESXi host based on a reference host you configured in advance.

One of the configuration settings in Host Profiles is the Active Directory (AD) configuration. As you can read in this post you can add your ESXi host to AD. This way ESXi is added to AD and can use AD for authentication.

The bug

And here is where my problem start. As you can see in my post I want my ESXi host to be added to the directory “OU=Servers,OU=ESXi” in my domain “DEVTEST.LOCAL”. When creating a host profile with from this ESXi hosts configuration, Host Profiles will only add the value “DEVTEST.LOCAL” to the “Configuration Details” of the Host Profile.

Now when applying the newly created Host Profile to a non-configured host, will result in an error that the host can not be joined to AD (Unless you have Domain Admin rights for the domain and can add computers to the the OU Computer). This is due to the fact that the specific directory structure isn’t added to the “Configuration Details” by Host Profiles when taking a snapshot of the configuration of the ESXi host.

Solution

How to solve this problem? Well actual the solution is very simple. Add the AD OU directory structure, in my case /Servers/ESXi, to the “Configuration Details” of the Host Profile. This can be done by manually editing the “Configuration Details” of the Domain Name under Active Directory Configuration. You just add the directory structure to the domain name. Also described in the note of this post.

Solution results in error : This solution will result in the ESXi host being added to the domain to the correct OU structure, but as a result the ESXi host will never reach the status Compliant. This is due to the fact that the Host Profile configuration states “DEVTEST.LOCAL/Servers/ESXi”, but the ESXi host presents the configuration as “DEVTEST.LOCAL” which results in an Non-Compliant status which is incorrect.

Hope this will be solved in the next release of VMware vSphere.

Citrix best practices for virtualizing XenApp

VMware already published a document about the best practices of virtualizing XenApp servers on top of VMware vSphere. You can read about it and download the document over here.

Now Citrix has published a best practice document, the XenApp Planning Guide: Virtualization Best Practics with their point of view on virtualizing XenApp servers. Note that this document not only focuses on virtualizatin XenApp on top of VMware vSphere, but also the hypervisors by Microsoft (Hyper-V) and Citrix (XenServer) are taken into account.

This document also contains a lot of useful recommendations. So I would recommend reading both the VMware document and the Citrix document carefully when designing your virtual environment

Overview of the Citrix document :

Desktop virtualization comprises of many different types of virtual desktops. One option is to use a
Hosted Shared Desktop model, which consists of a published desktop running on a Citrix XenApp
server.

One of the goals when creating a design for Hosted Shared Desktops is to try and maximize
scalability while still providing an adequate use experience. Hosted Shared Desktops provide an
advantage over other desktop virtualization techniques by only requiring the use of a single
operating system, which significantly reduces user resource requirements and helps improve
scalability numbers.

However, in order to get the most users, making correct design decisions as to the resource
allocation is important. Creating too many virtual machines or too few might negatively impact
scalability.

This planning guide provides resource allocation recommendations for users running on a Hosted
Shared Desktop on either Windows Server 2003 or Windows Server 2008.

Note: Even though these best practices are based on the Hosted Shared Desktop model, they are still relevant in a non-desktop model where users only connect to published applications without the desktop interface.

The XenApp Planning Guide: Virtualization Best Practices can be found here.

Disk selection in ESXi kickstart

Automated installation is the way to deploy your ESXi configuration to your servers. After all it’s all about automating your IT operations and making your life easier. Nobody likes to do a simple task twice, so I would definitely recommend to automate your ESXi installation. ESXi uses kickstart for automating your installation. You can view more details on this in my previous post over here.

Disk selection

All kickstart scripts start with the installation of ESXi. Afterwards you can add first-boot script to configure your ESXi installation to your specific needs.

One of the first thing you need to decide is where to install your ESXi installation to. The autopart command in the kickstart file specifies where you will install your ESXi to. You’ve got 3 options to choose from :

* Local = install ESXi onto the first local disk (local hard drive)
* Remote = install ESXi onto the first remote disk (FC or iSCSi LUN disk)
* Driver = install ESXi to the device which uses this driver in the vmkernel to access the disk

So if your using local disk select local and if your booting from SAN use remote.

But wait! There’s a catch…

Some local disks, specifically SAS disks, are not presented to ESXi installer as local disks, but as remote disks. This is also acknowledged by VMware in this KB article.

The solution is rather simple, but you do need to know the specific driver for the controller of your local SAS disk. In my case the server was a HP BL460c G6 blade. Thanks to this (Dutch) VMUG post I was able to trace the driver (hpsa) for the SAS controller in the HP BL460c G6.

And this is where the driver option of autopart kicks in. If you have several types of servers and always want to install to the local disk, use the following command :

autopart –firstdisk=hpsa,local –overwritevmfs

In this case ESXi first tries to install to the disk access with device driver hpsa. If that fail it will try to install onto the first local disk. If both options fail, the installation of ESXi will fail and you will error will be shown onscreen.

Hope this gives you some better understanding in how ESXi installs itself onto disk. For more information have a look at the Setup Guide of ESXi here.

What ports does vSphere use?

Ok, I have some knowledge about VMware vSphere, but I can’t remember everything. Good thing there are some people out there that have some good ideas about reference material. One of them is VMware Technical Account Manager Dudley Smith who created a nice diagram of all the ports used within a vSphere environment.

Check out the blog post over here and download the nice ports diagram in PDF format.

Update : Also check this KB article by VMware for ports used by VMware products.

Adding a ESXi host to Active Directory

Since vSphere 4.1 VMware has enabled Active Directory integration for ESXi into the GUI. This is a nice feature to elevate your security and make sure that your AD can be used for authentication on the ESXi host.

As with all computer account your need to be sure that the following is correct :

* DNS is configured properly on the ESXi host and can resolve AD
* ESXi host has a FQDN name and can be resolved by DNS (also correct reverse DNS lookup!)
* Time in sync with AD server for Kerberos

You can configure the directory services in the GUI by accessing the Host Configuration –> Authentication Services and then clicking the Properties. A configuration box will pop up and it will ask you for the properties for your Active Directory service.

Note ! If you want your ESXi host to be put into a specific directory in your Active Directory you’ll need to put the OU directory structure after the domain name. In my case devtest.local/Servers/ESXi in which the ESXi hosts reside in directory ou=Servers,ou=ESXi.

Next you will be asked for domain credentials (please use account@domain.suffix) with privilege to join computer account to the domain.The right credentials will add your ESXi host to Active Directory.