Rick Vanover

Virtualization tool bundles assist older OSes

Virtualization administrators are in a unique situation where older operating systems (OSes) can potentially “live forever” in the virtual world. While we may not wish to enable older OSes to remain in our environments indefinitely as virtual machines (VMs), situations arise where we need to do just that.

Recently, I had a situation where an older OS had been removed from the installable toolkit platform — in this case it was VMware Tools. The older operating system, Windows ‘98, had been removed from the VMware Tools installation with the release of VMware Server 2.0. While the need for a Windows ‘98 virtual machine is rare, it does exist.

To solve the immediate problem, I was able to install a VMware Tools .ISO image from the 1.0.3 version of VMware Server that I’d been using on another host system. Once installed, the older tools are listed as ‘out of date’ as expected, but the basic features of driver optimization are present on the guest VM.

At first this dilemma did not appear to be much of an ordeal, but it started an important thought process. While Windows ‘98 was the first occurrence of platform removal from a guest toolkit installation that I have observed directly, I don’t expect Windows NT or 2000 guestOSes to be that far from the chopping block of supported platforms.

One way to prevent this issue is to hold onto the tools installations for each platform of the hypervisor. VMware Tools, XenTools and Hyper-V Integration Services all exist as virtual CD-ROM .ISO images that you can hold onto for re-installation on another guest VM. Also, keep in mind that there may not be support from the host side either, so check to see which supported guest operating systems are available.

As you might expect, configuring an environment in this fashion may be met with some skepticism, as it could possibly divert resources. As a result, it may be worth placing this type of guest workload on a free hypervisor like VMware Server or on a similar lower tier of virtualization and storage. Having a flat file backup (.VMDK or .VHD) of the VM is a good idea as well.

While this situation is less than ideal for truly obsolete guest operating systems, the rare instance may arise where archiving toolkits can prove very beneficial.

Key concepts of Hyper-V Integration Services

Integration Services is Microsoft Hyper-V’s installation interface on guest virtual machines that is designed to optimize the drivers of the virtual environments and provide the best experience. Here is a rundown of what you want to know about Integration Services when getting started with Hyper-V.

• Integration Services are installed via virtual CD - For default installations, the C:\windows\system32\ path of the Hyper-V server contains the guest.iso file. This virtual CD provides the installation of Integration Services and is launched from the Action menu on the virtual machine as shown below:

• Integration Services are native on some platforms - Selected releases of Windows Vista and Windows Server 2008 are Integration Services aware and do not need to be installed specifically.

• New Services and the Control Panel - Integrations Services shows up as Hyper-V Guest Components in the Control Panel and installs five Windows-based services. These are Hyper-V Data Exchange Service, Hyper-V Guest Shutdown Service, Hyper-V Heartbeat Service, Hyper-V Time Synchronization Service and Hyper-V Volume Shadow Copy Requestor. These Windows-based services exist in the task manager as vmicsvc.exe.

• Ease of Use - The installation of Integration Services permits the full use of Hyper-V Manager through remote desktop connections. Without this installation, interaction with the guest VM within Hyper-V Manager through a remote desktop from a different system will not permit mouse use.

Installing the hypervisor driver packages, such as VMware Tools, VirtualBox Guest Additions or Hyper-V Integration Services is always a wise decision in order to optimize the experience for guest systems. The configuration and setup of Integrations Services is very light, and can be managed much like the other driver packages. More information on Hyper-V can be found on the Microsoft website.

Getting Started with Hyper-V Manager

Every good virtualization administrator owes it to themselves to survey the field. In today’s virtualization climate, this includes looking at Microsoft’s Hyper-V. Various Hyper-V configurations, including those on Windows Core installations, will need to add Hyper-V Manager to manage, run and configure virtual machines (VMs). Administrators evaluating Hyper-V may have trouble getting started on this step, so let’s go through the required actions to get rolling with Hyper-V.

For Core installations, including the recent free version of the hypervisor, Hyper-V Manager is not able to be run locally. One easy way to manage the remote hypervisor is to add Hyper-V Manager from a separate Windows Server 2008 installation. The most difficult part of getting started with Hyper-V is this specific step. Knowing where to add Hyper-V Manager is not intuitive, especially on the Core installations.

Windows Server 2008 is still somewhat young for widespread adoption in the data center at this point, so the initial configuration may take a moment to figure out. Hyper-V Manager exists as a feature for Windows Server 2008, and adding it is done from running Server Manager, selecting Features, Add Features, expand Remote Server Administration Tools, expand Role Administration Tools, and selecting Hyper-V Tools. This option is shown in the figure below:

Hyper-V Manager is now installed and ready for use on the server. It is important to distinguish that the Hyper-V Manager feature is not included with the Hyper-V Manager role as they are separate items from the Server Manager perspective. Servers with the Hyper-V role can be added to the Hyper-V Manager on the local installation. This takes a little thought to add from a permissions standpoint, and is best done through an Active Directory domain installation for distributed permissions.

For more information on Hyper-V Manager, check out the Microsoft website.

Making a P2V conversion: Tricks for systems with large storage

Converting a system with a large amount of locally attached storage can be a challenging task given the time required to perform the conversion. Here area a few tricks I’ve found that can help ease the pain on these types of conversion tasks.

• Private network: Making a private network between the physical host and the virtual host can provide two benefits. The main benefit is that conversion traffic will be isolated from the rest of the network traffic; the other advantage is that there is no risk of a user or process connecting to any resources and making changes during the conversion. The downside is that there may be special host-side configuration for a temporary network presence to allow the special network.
• Direct LUN mappings: For virtualization platforms that allow guest VMs to access a LUN directly, it can be much easier than performing a lengthy conversion of large data volumes that are already on a storage area network (SAN) and mapped to a physical system. Here is a blog post with a little more detail on that topic.
• Housekeeping: If there is junk on the physical system, does it need to be converted to the virtual environment, which may have more expensive storage? Clean up the candidate’s file system, and perform obvious tasks like emptying the Windows Recycle Bin. This allows for a more accurate re-sizing of the drives during the conversion.
• Agent backup and restore: For standard file volumes, such as a file server, it may make more sense to only convert the system drive and perform an agent-based restore to the virtual machine for the additional volumes. This does not necessarily save time from the entire conversion, but saves time within a tool like VMware Converter.
• Get a good time estimate: If you have to go at the large storage system as-is, make sure you have a baseline of about how many GB can be converted per hour. A good way to test this is to convert a good candidate system of about 100 GB and use that as a multiplier for your environment. There are a lot of factors, such as network speed and traffic, virtualization platform, storage systems (on both ends), and the conversion mechanism used. This allows for a good estimate on any downtime that needs to be coordinated if this applies to the selected workload.

These tricks can make converting a large amount of storage a little less daunting. What tricks have you employed to tackle physical systems with large amounts of storage in the course of being converted to a virtual machine? Leave a comment below and let us know.

Piloting a VDI requires partner involvement

A successful VDI pilot is a critical step toward embracing desktop virtualization technology when migrating from traditional desktops. In this video blog, Rick Vanover discusses how to go about creating a pilot to obtain optimal results without engaging vendors in the pre-sales capacity.

The first 45 days of using the virtual machine expiration date

In prior posts, I mentioned that determining how the expiration of a virtual machine (VM) will be managed and implemented is just as important as deciding to have an expiration date. I have been using Emobtics V-Scout since its release in early September of this year, and it is one of the quickest and easiest ways to get started with a VM’s expiration date for free.

Depending on the technology climate, the concept of a VM’s expiration date may or may not be received well by internal IT teams such as developers. I have taken the stance that test-and-development systems should have an expiration date. The expiration date can be extended, of course, but it is more important that it is a defined process. Certain VMs will not have an expiration date, such as a QA environment for a live system. This can be managed in the same fashion as well.

In my experience thus far, I’ve found that the process makes the requesting development teams a little more aware of the system footprint. There has been little resistance to the concept of an expiration date, and it is well communicated from the virtualization team to the requesting groups. Using V-Scout, the procedural steps are to define the owner of the VM as well as the expiration date. When a VM is provided to the requesting group, I generate the V-Scout inventory report. The inventory report is then saved and sent to the requesting group as a way to clearly identify the definition of the VM in the virtual environment. The V-Scout inventory report comes with information about the operating system version, amount of memory, owner information and email address, expiration date as well as other information. With this information, the report adds an element of service credibility to the virtualization administrator. The figure below is a sample report from V-Scout:

Since I have been using the expiration date, the requesters of virtual machines have been proactive in letting me know that the VM needs to be extended in duration. I don’t mind accommodating that request, as I’m trying to avoid a long list of systems that in four years nobody remembers anything about. This proactive request for an extension is very welcome and stems from a few other small practice issues that accompany the VM expiration date. The most noticeable of this is an automatically scheduled email that reminds the requester that the VM is due to expire in one week. The other part of that is a scheduled task in VMware VirtualCenter to change the power state of the VM due to expire. Lastly, there is another scheduled email that reminds me to remove the VM from the virtual environment storage and Windows Active Directory.

These small practice points with the use of a tool that fits your needs allows for an expiration date to be implemented without using more expensive lifecycle or lab management products. V-Scout is a free download from the Embotics website.

Defining a nomenclature for storage allocations

The relationship between the virtualization administrator and storage administrator can sometimes be less than cordial. Yet it can become less contentious when approached in a certain manner. One way that administrators can work closer with storage teams is to identify a nomenclature for shared storage resources in the virtual environment. This is critical because as virtual environments grow, storage management becomes an extremely important part of a successful implementation.

In larger environments where the storage and virtualization server teams are separate groups, there are a number of ways to organize a standardized nomenclature of a logical unit number (LUN). For example, the virtualization admin may only care about the size of the LUN and possibly the tier of performance. The storage administrator is concerned about those factors and more. As I’ve mentioned in the past, the process of getting down to details in the storage environment is critically important as the infrastructure grows. As time goes on, we simply can’t refer to the “500 GB LUN” or “the last one you gave me” anymore.

Recently I had an opportunity to work with an entirely different storage environment than I’m used to. As can be expected, this situation arose, but I perceived it as a great time to hammer out a crude yet effective specification for a LUN nomenclature. The situation involved a VMware environment connected to a Fibre Channel storage area network (SAN) with a number of storage devices presenting disks to the VM environment. The basic objective of having a standardized nomenclature is so both parties can determine which LUNs are available and the basic information present on them. The figure below shows the end result of this ad-hoc policy:

Determining a nomenclature for storage allocations will vary widely for different environments. Designations such as which tier the storage lies upon, whether it is developmental or live system storage, or which virtualization cluster owns the storage can all be elements of the process. Furthermore, if you’re dealing with a storage management system, the requirements for the name of the storage system may be different than the directly attached storage system in the example above. The end result for all parties involved is a far more orderly process with a much better understanding of how the storage is allocated in the virtual environment. In addition, the virtualization team will be able to more clearly communicate with the storage team about specific resources in use.

Out-of-band boot order configuration with Sun xVM VirtualBox

The configuration for virtual machine (VM) tasks that involve booting from anything other than the virtual disk can be inconvenient. Sun xVM VirtualBox offers a functionality that allows the boot order to be configured outside of the VM. For VirtualBox guests, the boot order can be configured in the VM’s advanced options. The figure below shows a VM’s configured boot order properties.

The limitation with this configuration is that the settings cannot be accessed through the VirtualBox interface while the VM is running, which makes advanced configuration a little difficult. Further, if the machine is in a saved state but not running, it cannot be configured. The vboxmanage command can perform this same configuration but it still requires offline access to the VM. VMware products have a BIOS for the VM, making configuration similar to that of a physical machine for boot order. With VirtualBox, there is not an accessible BIOS interface for the VM. During the boot process, however, there is a default option to access a boot menu by pressing F12. This functionality is shown below.

By VirtualBox not having a VM BIOS in a conventional sense, all relevant configuration is accessible from the interface. The four standard boot classes of hard disk, network, floppy or optical drive can be configured in the interface as shown above or with the earlier mentioned vboxmanage command. The following command will configure the boot order of the Solaris-Test VM:

vboxmanage modifyvm Solaris-Test -boot1 disk

I’ve mentioned the vboxmanage command before for amazing configuration options from the command line. In the case of boot configurations, virtual media (.ISO and .FLP files) can be configured as well.

Version 2.0.2 of VirtualBox was released on September 12, 2008. More information on Sun xVM VirtualBox can be found in the online user manual at the VirtualBox website.

VMware releases update to VirtualCenter and VMware Converter

Last week, VMware released VirtualCenter 2.5 Update 3. The release fixes issues with Update 2 (build 104263), which was released in July, before the infamous product expiration issue. In the immediate releases after the problem, a corrected version of Virtual Center was not released.

This update fixes 19 various issues but does not provide any new functionality. Several of the resolved issues involve VMware High Availability and Distributed Resource Scheduler functionality — in the previous version, various situations prevented the functionality from working correctly.

VMware Converter Enterprise, now on build 62407, also has an update that will correct two minor issues with connecting to a VirtualCenter server for conversions. This is different than the VMware Converter Enterprise standalone edition, which installs on remote systems instead of the VirtualCenter server. The standalone version remains at version 3.0.3 (build 89816).

More information on VirtualCenter 2.5 Update 3 can be found in the release notes on VMware’s website.

Did VMworld 2008 satisfy attendees?

While VMworld 2008 left some attendees and contributors to SearchServerVirtualization.com hungry for more from VMware and its partners, others may have a different take on the conference. In this video blog, Rick Vanover offers his opinion on what VMworld offers to attendees and if it is worthwhile to attend.