Virtualization author and programmer Eric Hammersley first realized the potential of virtualization technology when he installed multiple server and switch racks aboard U.S. Navy ships to support the IT-21 initiative.
Wrox Press later contacted him to write Professional VMware Server (Programmer to Programmer)
and Hammersley couldn't resist.
In this Q&A, Hammersley covers common issues encountered in an initial VMware deployment: base virtual machine images, freezing Windows guest operating systems with Sysprep, scripting and various VMware APIs.
SearchVMware.com: When system administrators deploy VMware for the first time, are there any common issues they encounter?
Eric Hammersley: It varies by the platform being used. The Windows flavor of VMware Server is pretty good. For the most part, the install and configuration is pretty intuitive. The Linux flavor, however, demands a bit more prowess on the part of the administrator. Depending on the complexity of your virtual machines and the security required for each, a common hurdle is configuring the access rights for each machine. VMware Server itself relies on the underlying operating system to enforce access to specific machines. This means the admin needs to be well versed in the specific security model for his platform. This can get tricky; however, it's not a huge hurdle.
Probably the most common question from readers is the configuration of virtual networks. The VMware product line as a whole offers a pretty flexible virtual networking model. This can be used to isolate your machines, build mini-networks, proxy, share, and the list goes on. My tip is always to keep it simple. You'll know if you have a complex scenario that requires that twisted, freak-of-nature-type networking setup. If you aren't sure, chances are you just need to keep it simple.
SearchVMware.com: In your book, you mention base virtual machine images. What is a base virtual machine image, and how is it used?
Hammersley: A base virtual machine image is just a phrase I use to describe a standard install image. I have no idea if I came up with it or read it somewhere. Regardless, the concept is simple: Imagine you need a Windows XP testing setup of Windows XP RTM, Windows XP SP1, and Windows XP SP2. One option, although not the best, is to build all three images from scratch. However, the use of base images makes the process much easier. Simply put, you would create a virtual machine image that contained just Windows XP RTM, the original release. This becomes your "golden image," if you will. You will never write to or use this base image in production. It exists so that other images can come to life. You would then utilize the base image to build other more complex images. Once you have a robust library of base images, you should never have to install or configure another operating system build. Just copy one over, install the patch level you need and fire it up. You can expand on the idea as well [and] creat[e] base images of specific patch levels if your environment is that complex.
SearchVMware.com: In Chapter 4 of your book, you explain how to freeze a Windows guest operating system with Sysprep. When would an IT pro want to freeze a guest operating system? Why?
Hammersley: Freezing the guest operating system is a very important step. Windows XP and beyond have unique SIDs [security identifiers] assigned to the machines. With the use of base images, if no steps were taken to change these SIDs, you would fill your logs with conflicts and errors from SIDs on your virtual network. Remember, all your virtual machines exist from a root, or parent, virtual machine base image. Without additional steps, such as changing the SIDs, they would all essentially be the same installs.
Now, you could get around this by using one of the many SID changers available on the Internet; however, it would have to be done by hand and done every time you create a new image. Using Sysprep offers a way to roll a Windows install into a state of "pre-first" use. It will generate new SIDS automatically, allow you to configure specific aspects of the machine -- like networking setup, printers, even domain and workgroup memberships -- before the first full boot. This can be accomplished with Sysprep's scripting, outlined in Chapter 4.
One thing I want to point out about base images that I make very clear in Chapter 4 of the book as well is to watch your software licensing. Ensure you have sufficient licenses to support your base images and their children. Refer to the operating system documentation for further information.
SearchVMware.com: How are vmPerl, VmCOM and Vix used? What are the differences between the three?
Hammersley: All three are the names for the VMware APIs. These allow you to write programs and scripts that leverage functions on your remote VMware installs. VmPerl and vmCOM are older APIs that are now at their end of life. Both support the same feature set but allow you to leverage them in different ways. VmPerl of course works with Perl, and vmCOM allows the use of Microsoft scripting languages like VBScript. They are somewhat limited in their function, but for many years it's all we had.
Vix is VMware's newest scripting API and what we power users have wanted for many years. It offers a greatly expanded feature set allowing you to perform almost any function against your server or virtual machines. It has some growing to do, since some advanced functionality is still lacking. However the potential is huge.
SearchVMware.com: Which virtual server processes can an administrator automate? Are there specific processes that should be automated?
Hammersley: You can automate nearly everything. While the scripting chapters cover the Perl, COM, and Vix APIs, the focus going forward should be on Vix, as I said earlier. The Vix API at the time of writing was just a first version, so its functionality was limited; however, the framework was in place to support everything from error handling and virtual machine power states to snapshot management and configuration. Once Vix has matured, there will be little left in terms of scripting that you cannot do.
What should or shouldn't be automated varies greatly [given] the environment. Processes that can be automated and are relatively simple are powering on and off virtual machines with error handing and recovery. There are scripts demonstrating this in the API chapters of the book. They are probably the most common items to script and have the most utility for the masses.
Let us know what you think about the story; email: Hannah Drake, Associate Editor.
This was first published in January 2008