Rick Vanover

No room for VMFS haters here!

Fresh off the release of my recent SearchVMware.com tip on the inner workings of VMware’s vStorage VMFS, I came across a VMFS-hater blog post. I am a big fan of VMFS for VMware implementations, frequently referring to the popular clustered file system as the most underrated technology VMware has ever made. Continued »

Virtualizing Microsoft SQL? Consider per-processor licensing

In a recent SearchVMware.com tip, I outlined situations where it does not make sense to have SQL or Exchange virtualized. The bottom line is that licencing depends on many factors, and you need to consider licencing when virtualizing such applications or you could end up spending more money than necessary. One point worth noting that is not in the tip is if you opt to license Microsoft SQL Server per-processor, it may carry additional benefits.

Continued »

Using vCenter Converter to create VMware ESXi virtual machines

Administrators considering VMware ESXi may wonder if vCenter Converter will workfor VMware ESXi conversions. The answer is yes, but there’s a gotcha.

Converting a physical machine into an ESXi virtual machine works best when you use the latest version of VMware Converter, version 3.0.3. While prior releases, such as 3.0.2 had support for ESXi, it has improved greatly with the updated 3.0.3 release. ESXi has a more updated version as well, version 3.5 Update 3. Likewise, if you are using PlateSpin’s PowerConvert or Vizioncore’s vConverter, you should make sure the version you are using supports ESXi as a target.

For most situations, converting machines to an ESXi host is not a big deal. The only practice issue that you may encounter would be the destination log-in selection of the converted virtual machine. Like many administrators, I have frequently used vCenter as the destination. If vCenter is not present in ESXi, ESXI will use the host as the destination log-in. The figure below shows the log-in:

Performing P2V conversions directly to ESX or ESXi hosts (no vCenter credentials) will use the local password to authenticate, and root is the default credential for ESXi. Beyond that, vCenter Converter converts machines to ESXi host nicely. Guest conversions can be placed in resource pools if set up on the host, as well as selected storage on VMFS volumes that are iSCSI, local,or fibre channel SAN. More information on vCenter Converter can be found on the VMware website.

Getting started with iSCSI and VMware ESX

Many VMware ESX administrators are quite comfortable with fibre channel storage but have not ventured into the iSCSI world. I recently set up my first iSCSI configuration for a small VMware Infrastructure 3 installation and it was quite successful. Here are some takeaways:

iSCSI is quite easy to configure. ESX’s iSCSI support is fully available in the form of a software initiator that uses a VMkernel interface. “That easy?” you ask? Yes, it is really that easy.

Using Ethernet is convenient. Until this point, I have exclusively used fibre channel storage for virtual machine file system (VMFS) volumes. With the ESX iSCSI software initiator, I simply dedicated some gigabit network interface cards to the VMkernel interface and was ready to configure the iSCSI adapter. There is experimental support for a hardware initiator with the QLogic 4010 interface.

There is a minimal configuration for the storage adapter. ESX has an iSCSI software adapter listed in the storage adapters section of the VMware Infrastructure Client. Once you configure this interface, the system is ready to receive a LUN. The figure below shows the configuration of the software iSCSI interface:

After those pointers, I was quickly running with a LUN provided from the storage system. Once the LUN is presented to the host, it is indistinguishable from other VMFS volumes. Full VMotion, Distributed Resource Scheduler and other VMware tools are available on these volumes, including the esxcfg- series of commands.

If you are getting started with iSCSI, be sure to go through the drills related to configuration steps on ESX. Also, visit your system architecture plan and make sure that the iSCSI interfaces are provisioned well by not also holding other traffic, and be sure to check out VMware’s iSCSI configuration document available for download from the VMware website.

P2V conversion success: Disable non-plug-and-play drivers

While performing a physical-to-virtual (P2V) conversion isn’t a new trick, there are always additional enhancements that can be performed to ensure a clean transition to a VMware platform. Recently when performing a P2V conversion, one particular system was not behaving as expected after the conversion was complete. While I have mentioned before that removing drivers from the new guest virtual machine is a good idea, this particular system required some more attention.

I found that some of the device drivers that were loaded in the Windows guest operating system even after all driver software was removed. Further, after the P2V conversion the hardware would not be enumerated in the hardware inventory because it was not present. This particular system had SAN connectivity before, and the drivers related to the fibre channel interface were causing me concern related to disk access, and a lot of errors in the local log. On the VMware virtual machine, the driver installed by VMware Tools provides all of the required disk access and I needed to stop this physical system hardware driver from filling up the error log.

The driver was listed in the Non-Plug and Play Drivers section of the Windows device manager. To view this section, be sure to view the hidden devices in the MMC snap-in for Windows Server 2003 systems. The figure below shows this area of Windows:

Once I identified the driver that was causing the issue, it was quite easy to disable the device. On subsequent boots, the offending process did not fill the Windows logs up with the errors related to the device not being present.

Considering Sun Ray server software for VMware VDI platforms?

Planning a virtual desktop infrastructure implementation is an incredible task on many accounts. Many administrators that are familiar with server-based virtualization are sharpening their skillsets in regards to planning a VDI implementation.

A virtual desktop infrastructure (VDI) solution is a collection of three main components: the user device, the broker software, and the back-end hypervisor. The Sun Ray series of devices are among the more refined products in the space, check out this SearchServerVirtualization tip for more on their features, pricing, and capabilities. For administrators who prefer to use an ESX hypervisor for their VDI, the Sun Ray server software can fill this void. Sun Ray server software runs on Sun Solaris and connects the devices to a VMware View broker. While this configuration does add another component compared to a native VMware View solution, there are benefits to using the Sun Ray devices. Sun Ray devices are a mature product line that allows any Sun Ray to connect to Sun Ray server software to be provided a connection. This helps with utilizing existing resources as well as interoperating with mixed versions of their current equipment, which includes three separate models. The architecture using Sun Ray connectors to VMware is shown in the figure below:

Test drive Sun Ray devices and software

Setting up a Sun Ray server software installation is not overwhelming. In fact, Sun makes it quite easy by working to simplify the process and break down the steps for administrators considering Sun Ray software. In this Sun blog post, it is broken down to a few steps that any virtualization administrator can tackle.

Each component requires thorough planning

Like many administrators, I prefer to seek a VDI solution that has ESX for the hypervisor. This is simply due to the memory overcommit technology and the new linked clone technology of VMware View. These two pieces make the hypervisor selection quite easy in my opinion. Selecting the device, and any broker accompaniments are important to delivering a robust VDI installation.

More on restoring ESX from backup

In reading fellow SearchVMware.com IT Knowledge Exchange blogger Edward Haletky’s post on restoring the ESX host from a backup, I would like to say that I concur with all of his points and would like to add a few of my own.

I do not back up the ESX host in a way that I would ever want to restore it. Occasionally, there are needs for onetime backups of VMDK files or such that are well suited for an agent backup, but for the most part the hosts are a transient set of resources that I present vCenter.

There are some practice issues that can optimize how this preference can be used, and I’ll share a few of them here. Some of these I currently use in production, some I have used in lab functions only.

Before you locally destroy a server’s state, it may be a good idea to run the vm-support tool or generate diagnostic bundles before the system is gone forever. Of course, this is not always possible, but it is a nice way to have the critical logs available before the installation is replaced.

One of the first points is the server reinstallation time requirement. Simply installing ESX is quite easy and can be done in twenty minutes or so. Some large ESX environments may want to look into an ESX kickstart script. These scripts can provide a scripted out answer file for the ESX install and can be made to work on a PXE boot. This can not only slightly reduce the reinstallation time, but can also ensure configuration consistency.

Now that ESX is configured, you may have a wonderful time reconfiguring all of the virtual switches and port groups. ESX has some native help here with the use of the esxcfg-vswitch series of commands, (check out the link for a blog post I did earlier that can get you started using this command). I’ll also pass along a site I recently came across with some good tools from Richard Garsthagen, a Netherlands-based VMware evangelist who has a cool blog with some good ESX tools that can help in this area, especially with the ITQ VLAN and portgroup manager tool.

The last series of configuration in a re-installation can revolve around storage pieces, such as multipath policies, iSCSI, or host bus adapter (HBA) information and configuration may also be optimized by making scripts with the esxcfg series of commands.

Finally, again echoing Edward’s comments, the best tool to have is good documentation and a confidence in the installation. This will permit the reinstallation to succeed smoothly and in a timely fashion.

VMware offers new searchable compatibility for support resources

In October of this year, I mentioned in a prior blog post that VMware updated their storage and compatibility guides to reflect a split of sorts between ESX 3.0.x and ESX 3.5 and ESXi. This is now available as a searchable by product name or hardware vendor for multiple solutions and provides a central resource for all supported configurations. This tool allows for the following search categories:

Systems - What products are supported for installations for ESX and ESXi platforms
Storage and SAN – Allows searches for partners and their products for ESX and ESXi-based storage devices.
I/O devices – Has brand information for supported HBAs, RAID controllers, and SCSI adapters.
VMware View – Lists supported connecting devices to the new virtual desktop product.

This new hardware compatibility guide search website also has direct links to all of the relevant other configuration information. This includes resources on CPU configuration for VMotion, supported guest operating systems, as well as my trusty PDF documents that are available as a traditional download.

More information on the new tool can be found in the online help section of the hardware compatibility guide website.

Focusing on the consolidation ratio in planning virtual environments

Recently, myself and other bloggers as well as the editorial staff at TechTarget were invited to a briefing on Hyper-V. Microsoft is, on all fronts, trying to get Hyper-V and the Microsoft System Center technologies into the hands of administrators, and to some extent it is working.

During this briefing there was some discussion about the memory overcommit technology of VMware’s ESX, not available in Hyper-V. This feature pretty much answers my question on where I put my virtualization environment. Microsoft said IT managers and administrators won’t make their platform decisions based on one specific technology feature such as memory overcommit. I could not make sense of that answer, so I chewed on it a little and came up with this.

Managers and administrators do make their platform decisions on factors like the consolidation ratio, which is the number of guest virtual machines that are running on one physical host. In the case of VMware versus Hyper-V, there is no question which is going to perform better in achieving a higher density of guests per host. This ratio is made almost entirely possible by the memory overcommit technology that ESX has. To that end, how important is a consolidation ratio? Granted there are many factors that go into the workload and various planning tools that can be used to map out the virtual landscape, but for me, I can’t think of a more important measurable in architecting a virtual environment.

Failed P2V conversion? Check DNS

In the course of performing many physical-to-virtual (P2V) conversions, I still come across situations where a small configuration can make or break the task. Recently, I performed a P2V conversion of a system that was successful in all measurable elements from the VMware Converter and ESX-based virtual machine standpoint, yet the application was not functioning as expected. One important part of this conversion is that the virtual machine changed networks during the conversion. Everything checked out locally on the virtual machine, including DNS configuration, subnet mask and the IP default gateway. Yet the application still had issues working correctly.

Later on, I had discovered that there was a DNS record for the same IP address of the converted system. In this scenario, the workload had a separate DNS name that was in use by the application and not exclusively using the host name. Further, I believe that the  record was a previous computer name of the converted system, and the application had some calls that still used the old name. Before I noticed this entry in DNS, I had checked the local host file on the Windows virtual machine to ensure that there were no entries pointing to an IP address other than 127.0.0.1 for any local references.

So what can be done to make sure that this bizarre information does not happen again? In the pre-conversion steps, take a look through the DNS zones and see if the IP address or the hostname are pointing to anything that references a specific IP address. While applications may have configuration beyond the scope of a P2V conversion, identifying any DNS or host file configuration before the conversion can save some frustrating and possibly unexplained application failures.