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.

The launch of VMware Press

Microsoft has it, Cisco has it, so it’s not a surprise that VMware launched it’s own VMware Press. And if I may say so : it fills a gap. The last couple of years the portfolio of VMware has grown from a virtualization vendor to a full size cloud company that can deliver a full range of IT infrastructure software. With this growth also the demand within the IT community has grown for more information and good books about the products that VMware delivers.

This demand up till now was filled by for example Duncan Epping, Mike Laverick and Scott Lowe and many more who piece by piece delivered excellent pieces of work on subjects of VMware, virtualization and cloud computing. Now VMware created it’s own VMware Press brand to deliver books with the same magnificent content of your favorite VMware product.

VMware Press is a joint venture between Pearson and VMware. The joint venture must result in books in the following fields :

* Technical books, ebooks, and videos that concentrate on specific applications of virtualization.
* Decision Maker books, ebooks, and videos that focus on the business aspects of virtualization.
* Official certification materials that support VMware’s complete certification program.

And of course the press release of a new book label would not be the same without the introduction of some new books to be released in the fall of this year

Coming Soon from VMware Press

Storage Design and Implementation in VMware vSphere 5.x
by Mostafa Khalil • Technology Deep Dive • Fall 2011
In this technology deep dive book, expert architect Mostafa Khalil teaches everything an administrator or architect needs to know about design, management and storage maintenance in the vSphere 5.0 virtual environment, including detailed procedures and guidelines, architectural design elements, best practices, common configuration details, and more.

Administering VMware SRM 5.x
by Mike Laverick • Technology Hands-On • Fall 2011
In this practical and technical guide to installing and configuring VMware’s Site Recovery Manager 5.0, expert Mike Laverick takes readers through set-ups for multiple vendors, disaster recovery, common pitfalls and errors, while along the way explaining why things happen, and how to fix them.

Automating Day-to-Day Administration of VMware vSphere 5.x
by Cody Bunch • Technology Hands-On • Fall 2011
This hands-on technical guide to automating vSphere with Orchestrator teaches administrators how to save time and resources by automating their virtual infrastructure. Automation expert Cody Bunch teaches valuable practices and tool use through a combination of real world automation examples and case studies.

Must say I’m excited about VMware Press and looking forward to read the books!

A different view on View

Yesterday I attended the VMware Partner Exchange on Tour here in the Netherlands. You can view an impression of this event on the site of Mr. Sloof over here. One of the session I attended was the one given by Raymond van ‘t Hag about the VMware View reference architecture.

Raymond is one of the specialist on VMware View in the Benelux and delivered a nice presentation about using View in combination with local SSD disks.

An interesting view on how to implement View as you can say. Since the era of server virtualization kicked in we’ve moved away from servers with local storage to SAN connected servers. This solution brings us back again to the local disks in the server. An interesting point of view if I may say so myself. But then again it has advantages with regards to disk utilization and creates a VDI solution that also can be implemented at companies that don’t have the budget for an expensive SAN solution.

VMware released a whitepaper about this View solution in a whitepaper. You can download the whitepaper over here.

During the presentation Raymond also mentioned the VMware View & Fusion-io VDI appliance. This solution is created by VMware SE Ton Hermes and delivers VDI-in-a-box. This solution is VMware View in combination with Fusion-io (faster then SSD!) and can be seen as a ready-to-use VDI solution which you can buy off the shelf. The brochure can be found here.

In all I think these are nice solutions for VMware View which definitely state that VDI is something for all companies. You don’t have to be a million dollar company to implement VDI. These solutions make it possible for any company to work anywhere, anytime and anyplace!