Category Archives: Scriptng

Maybe VMware Needs a Quality Oversight Department…

I was doing some research for session I am presenting at an upcoming PAVMUG session about vSphere remote management when I came across an apology by one of the PowerGUI guys. Essentially, he was apologizing for something that VMware changed in the functionality of PowerCLI that affects how the PowerGUI Virtualization Powerpack interacts with it.

Read more »

Creating an Automated ESXi Installer

Back in the summer, I saw Stu’s Post about automating the installation of ESXi. I was reminded again by Duncan’s Post. Then, I found myself in a situation when a customer bought 160 blades for VMware ESXi. With this many systems, it would be almost impossible to do this without mistakes. I took the ideas from Stu and Duncan and created an ESXi automated installer that works from a PXE deployment server, like the Ultimate Deployment Appliance. I took it a step further and added the ability to use a USB stick or a CD for those times when PXE is not allowed. The document below is a result of it.

This is a little different than the idea of a stateless ESXi server, where the hypervisor actually boots from PXE. This is the installer booting from PXE so that the hypervisor can be installed on local disk, an internal USB stick or SD card. You could also use it for a “boot from SAN” situation, but extreme care should be taken so you don’t accidentally format a VMFS disk.

As always, if anyone has comments, corrections, etc., please feel free to post a comment below.

The document can be found here -> Creating an Automated ESXi Installer

Summary

The ability to use an automated, unattended installation routine for a hypervisor is necessary whenever it is deployed to multiple systems or is done frequently. Automated installations help avoid a misconfiguration caused by human error, which become common when repetitive tasks are performed.  Because the “traditional” version of VMware ESX Server contains a Red Hat Linux based console operating system, we have been able to leverage kickstart scripts for automated installation. With the ESXi hypervisor, much of this functionality is not available because of the smaller footprint.

This document explains how to set up ESXi with little intervention. The modifications explained here can be used to deploy ESXi using a PXE server. In our examples we will use the Ultimate Deployment Appliance, but these methods will also transfer to such commercial packages as HP Rapid Deployment Pack, Altiris, or even a home grown PXE server. The modifications can also be used for deploying ESXi using a USB stick or a customized CD.

Requirements

  • ESXi Server Installable The ESXi CD image can be downloaded from the VMware site, however using a systems management and monitoring server, such as HP SIM or Dell OpenManage is highly recommended. Since there are usually vendor specific CIM providers to enhance the monitoring capabilities, some vendors will provide a customized CD image with the CIM providers. These additional CIM providers will also allow for more information to be displayed in the hardware sections of the vSphere Client. A search for “ESXi” on the HP and Dell sites produced links to the latest customized images.
  • Deployment Server A deployment server will allow for a controlled, automated installation of the ESXi Server software. The ability to handle multiple operating system installations is also desired. The ability to provide PXE and DHCP services is required as well. Most times, the deployment server will be running PXE services and TFTP. The DHCP services may be running on a different server in an enterprise. This document does not explain how to set up a separate DHCP server. For this document, we will be using the Ultimate Deployment Appliance (UDA) version 2.0 (beta).
  • Virtualization Software The UDA runs as a “Virtual Appliance,” which is a pre-configured virtual machine. It will run under VMware ESXi (available as a free or licensed instance), VMware Workstation (available for purchase), VMware Player (free) or VMware Server (free). In this document, VMware Workstation is used.
  • Optional software Although no additional software is required when using the UDA, you will need additional software if you plan on using a USB stick or if you plan on creating a customized CD image:
    • VMware Converter If you plan on using ESXi or Server to host the UDA, VMware Converter can be used to import the virtual appliance.
    • Syslinux In order to make a bootable USB stick, you will need the syslinux utility. This utility is available for Linux and Windows. The UDA does not include it. As an alternative, you can use the unetbootin utility.
    • CD Imaging and Burning In order to create a bootable CD image, you will need software to create the CD image (mkisofs) and then software to burn the image to the CD media (cdrecord). The cdrtools project includes versions for Linux and Windows. Most Debian versions of Linux, such as Ubuntu, come with the cdrkit, which uses genisoimage for imaging and wodim for burning.
    • Linux Desktop If you look at the contents of the ESXi CDs using Windows (Windows 7 was used), you may see all of the files listed using all capital letters. Since the ESXi software is based on Linux, all file operations are case sensitive and expect the files to be all lower case. This may cause errors when attempting to create the automated installer. For this reason, a Linux desktop is recommended. For most of the operations, UDS may be used. The only missing software on the UDA is syslinux. For a feature rich Linux desktop, Ubuntu is recommended. A few pre-configured Ubuntu Desktop virtual appliances are also available.

Conclusion

Once you have a hypervisor installed you will need to configure the server and add it to vCenter in an automated fashion. Look for a future doc covering this. For now, check out these resources for post install configurations:

http://communities.vmware.com/docs/DOC-7364

http://communities.vmware.com/docs/DOC-7511

http://communities.vmware.com/docs/DOC-8170

Changes to the ESX Service Console and ESX vs. ESXi…again

A whitpaper was posted in the VMTN communities Thursday outlining the differences between the ESX 3.x and ESX 4.x service console. It further offers resources for transitioning COS based apps and scripts to ESXi via the vSphere Management Assistant and the vSphere CLI. Also mentioned briefly was the vSphere PowerCLI. If you are a developer or write scripts for VMware environments, also check out the Communities Developer section.

I hear it time and time again…The full ESX console is going away. ESXi is the way to go. I know there are valid arguments for keeping ESX around, but they are few. Failing USB keys may be a valid argument, but I have not heard of this happening. If that is the case, use boot from SAN. You need SAN anyway. As for hung VM processes, there are a few ways to address this in ESXi.

If the techie wonks at VMware are publishing articles about how to transition to ESXi, then resistance is futile…you WILL be assimilated…

Get Hal's PowersHell Book Here!

This is just a shameless plug to try selling books on DailyHypervisor.com…As you already know, Hal Rottenberg has written a book called “Managing VMware Infrastructure with Windows PowerShell TFM

Get it here:

Managing VMware Infrastructure with Windows PowerShell TFM

Hal's New PowersHell Book!

If you want to learn something about PowersHell and the VI Toolkit for Winders, the community forum is the best spot right now. Hal Rottenberg is one of the pillars of that section of the forums. Always glad to help figure out your code when things are not working and always ready to explain what the heck is going on with it. I think he taught me most of the things that I know about the VI Toolkit.

Well he has written a book called “Managing VMware Infrastructure with Windows PowerShell” Stop over to his blog and pre order the book. I am sure it will become a valuable asset in your tech library.

What are you waiting for? Get out your credit card!

Script to Restart VMware Tools Remotely

I was “forced” to learn how Powershell and the VI Toolkit works for an engagement a few months ago. Once you learn how powershell works and how the VI Toolkit integrates with Powershell, you will love it. This is coming from a linux guy who sees some of the VBScript stuff and just goes “HUH?!?” If you like VB SCripts, check out this post on Jase’s Place. Back in the day, I knew DOS scripting pretty well and I have learned rudimentary bash and perl scripting. To be frank, Powershell was easy for a knucklehead like me to pick up. I use it frequently to automate tasks in VI3 and the winders VMs it manages.

In my last post, I mentioned that VCB snapshots will cause VMware Tools to appear to go off line, even though they are still running. The fixes were to restart the management services on the host or login/logout of the guest. Restarting the management services on the host could cause issues if someone set up to automatically start VMs on boot. Logging in to the VMs is fine unless you have hundreds of VMs.

A third option is to restart the VMware Tools service. This is something that can easily be scripted as long as you have admin access to the guest via RPC services. There are a few methods to script the restart of services on a server remotely. The first is using the sc.exe utility. The syntax of the script looks like this:

sc.exe \\guestname stop VMTools
sc.exe \\guestname start VMTools

This can be easily scripted using the good-old DOS for command. Create a text file (C:\scripts\serverlist.txt) with all of the servers that need to have the VMware Tools service restarted, one guest per line in the file so it looks like this:

guest1
guest2
guest3
guest4

Then run a command that looks like this:

For /F %%SERVER in C:\scripts\serverlist.txt do
sc.exe \\%SERVER stop VMTools
sleep 10
For /F %%SERVER in C:\scripts\serverlist.txt do
sc.exe \\%SERVER start VMTools

You can get the sleep utility in the Resource Kit Tools for Windows 2003. A 10 second pause seems to work pretty well to make sure the service actually stops.

Since I lost all of my DOS scripting chops, I only know how to automate this fully using the VI Toolkit and Powershell. The script below will use the VI Toolkit to automatically create a list of guests that report as not having VMware Tools running and pass that information to standard powershell commands to stop and start the services:

#Connect to the vCenter Server
Connect-ViServer <vCenter.FQDN>

#Get a list of guests where VMware Tools are not running
$servers = get-vm | where { $_.PowerState -eq “PoweredOn” } | Get-VMGuest | where { $_.State -ne “Running” } | select vmName, State

# Stop VMTools Service
foreach ($srv in $servers)
{

Write-Host “Stopping services on $srv”
# Get the VMTools Service
$Service = get-wmiobject -ComputerName $srv -query “select * from win32_service where name=’VMTools'”
if ($Service -ne $null)

#Stop the VMTools Service
{$Service.StopService()}

Sleep 10
Write-Host “Starting services on $srv”

#Start the VMTools Service
$Service.StartService()
}

Another thing I recently needed was a quick way to list the guests with snapshots as a quick method to make sure VCB exited properly. You can use this:

Get-VM | Get-Snapshot | Select VM, Name, Created, Description

Well, there you have it. Script your VMware Tools restart…
:o)