Posts Tagged ‘Virtual Infrastructure Client’

Virtual Infrastructure Client and the Windows Registry

June 17th, 2009

Hello gang. I apologize for the frequency slowdown in blog posts but I’ve been  _insert lame excuse everyone has heard before here_. Truth be told, I am busy working on a project which I hope to have available the virtualization community on or before VMworld 2009.

This post is a no brainer, maybe you’ve seen it before on another blog or maybe you’ve figured it out for yourself. For me, I can honestly say it was the latter, but with some minimal registry skills, it’s not so difficult.

In short, my Virtual Infrastructure Client (VIC) cached list of host connection entries (at the login prompt) had gotten much too polluted over time with many stale entries that I wanted to get rid of. This can happen over the course of time if you use your VIC to connect to many different vCenter servers or explicit hosts in various environments. Particularly, I would think this can happen quickly to consultants who travel from site to site supporting virtual infrastructures.

There is a way to manipulate the cached list you see in the pulldown box. And by manipulate, I don’t just mean delete. In addition to deleting entries, you can also modify entries (perhaps for a DNS suffix migration), re-order entries (VMware doesn’t maintain this list in alpha order necessarily or perhaps you’d like a custom sort order), or add entries (consider a scenario where you have a packaged VIC that you want to roll out to your new VMware admin – instead of presenting the new admin, who has no knowledge of the environment, with a blank VIC, help them hit the ground running with a pre-populated list of vCenter servers or ESX hosts to connect to).

As the title of this post indicates, the cached entries are stored in the Windows registry and are tied to each individual user profile (HKU). You’ll find the comma delimited list of entries in the following registry key:

HKU\\Software\VMware\VMware Infrastructure Client\Preferences\

The value name is RecentConnections and the type is REG_SZ

There’s one more value nearby that sticks out like a sore thumb:

HKU\\Software\VMware\Virtual Infrastructure Client\Preferences\UI\SSLIgnore\

The value names vary by connection name or IP address and the type is REG_SZ. These represent each connection where you’ve checked the little box telling the VIC that you want to ignore SSL certificate warnings which you will receive in an “out of the box” configuration. I can’t think of a great use case scenario why someone who has chosen to ignore SSL warnings would want to re-enable them, other than a situation where they’ve now enabled legitimate SSL.

To find out why disabling SSL warnings might not be such a great idea, see my previous blog post titled SSL Integration With VirtualCenter.

As they say in the ARMY, or at least on M*A*S*H… “That is all”.

Force vCenter Server update to reflect .vmx changes

May 2nd, 2009

Virtual infrastructure administrators may edit a VM’s .vmx configuration file by hand with vi or nano (my favorite) for a variety of reasons. Efficiency through bulk changes via scripting, troubleshooting a problem, adding unsupported/undocumented .vmx parameters, or a higher comfort level with command line interfaces to name just a few.

Modifying .vmx files by hand is all well and good. Administrators have been doing since since for as far back as I can remember with VMware products. There is an annoying caveat with VMware vCenter Server however. Changes made by hand in the .vmx file may take a while to show up in the Virtual Infrastructure Client. For example, if I’m looking at a VM’s configuration summary in the VIC, and then modify the .vmx file to change the memory configuration from 256MB to 512MB, save and exit, nothing seems to happen in the VIC. I’m looking at the VIC and configured memory of 256MB is staring back at me. It may end up staying this way for quite some time. Removing the VM from inventory and re-adding it to inventory will resolve the issue but that’s drastic, annoying, and it presents the opportunity for more problems. For instance, what if during the import of the VM it lands in the wrong resource pool or VM folder? Suddenly you’re exposed to potential resource contention issues impacting SLAs and incorrect permissions or patch management baselines on the VM.

There’s an easier way that involves a lot less risk using two vimsh commands at the service console. Here are the steps:

  1. Log on to the service console on the host that the VM is registered on.
  2. In the service console, make the configuration change in the .vmx file and save it.
  3. In the service console, run the command vimsh -ne “vmsvc/getallvms” |grep to obtain the VmID of the VM. The VmID will be the first number displayed on the left. Excluding the |grep portion of the command will display all VMs registered on the ESX host.
    vimsh -ne “vmsvc/getallvms” |grep knoppix
    80 knoppix [msa1000_lun3] knoppix/knoppix.vmx otherLinuxGuest vmx-04 Veeam Backup: Time [4/30/2009 5:46:41 AM], Backup host [SKYWALKER], Backup file [V:\VeeamBackups\Galleon Cluster Backup.vbk]
  4. In the service console, run the command vimsh -ne “vmsvc/reload using the VmID obtained in the previous step.
    vimsh -ne “vmsvc/reload 80″
  5. After a few seconds, the configuration change will be received by the vCenter Server and will be reflected in the VIC.

vimsh is a very powerful command line tool. To check out more of its goodness, take a look at xtravirt’s vimsh documentation.

A random collection of what’s new vSphere eye candy

April 20th, 2009

I’ve been testing vSphere for a few months and have collected various samples of new and different management interfaces. VMware has informed me that I am no longer under vSphere NDA and bloggers are welcomed to help showcase VMware’s new vSphere product. In no particular order, here are some of my observations. By the way, the very first thing I noticed out of the gate when installing vSphere (other than I needed 64 bit hardware) was that although ESXi4 is small enough to fit on a CD, ESX4 is now a DVD. For those who install from physical media, you’ll want to be sure you’ve got a DVD-ROM reader in your host.

The VIC now has integrated authentication built into the GUI. We had this in VI3 but through command line parameters that launched the client:

4-20-2009 10-11-43 PM

A Hyper9-like quick search in the top right area of the vSphere Client:

4-20-2009 10-37-15 PM

Complete license management overhaul evident in many areas:

4-20-2009 10-22-14 PM



4-20-2009 10-44-57 PM

4-20-2009 10-45-38 PM

An improved Plug-in Manager:


Host Profiles will assist us with automated configuration and consistency. This may sunset much of the deployment scripting you have in place today and I think it’s especially helpful for ESXi users as it offers yet another option for automating the configuration of VMware’s console-less hypervisor.  Along with being responsible for making configuration changes across a container, it can also be used to verify compliance of host configurations.  It works similar to VMware Update Manager and remediation:


vCenter Server configuration Advanced Settings. Take a look at what’s highlighted: VMotion encryption. Those worried about vampire taps on their VMotion network can sleep better at night:


My favorite and most used – the Home button, which brings you back to the “root” of all configurable items in vCenter Server. This feature alone will reduce VI Administrator mousing carpel tunnel by 20%:

4-20-2009 10-39-54 PM

vCenter Service Status. Keeping vCenter Server healthy is becoming increasingly important in vSphere. This tool helps us keep tabs on it:

4-20-2009 10-41-59 PM

VMware HA configuration. Note the new Admission Control Policies:


Back on the Cluster view, VMware HA offers Advanced Runtime Info, while DRS offers some standard deviation numbers:


…along with fancy new bar charts for resource distribution:


4,088 ports supported on vSwitches… 3,000 more than VI3 supported:


Resource Allocation at the VM level. The bar graphs look similar to the old ESX or GSX MUI, I forget which:

4-21-2009 1-15-21 AM

That’s all for now. I wanted to get into vNDS (vNetwork Distributed Switch) but that in and of itself is about 35 screenshots. Good material for later. vSphere looks and feels very promising. I like most of the changes but there are still some lingering enhancements that I will continue to pester VMware about.

VMware Tools “Not Running”

March 31st, 2009

I ran into an disturbing problem this evening in the lab. While in the Virtual Infrastructure Client (VIC), I attempted to perform a graceful shut down on a VM by right clicking on it and choosing Shut Down Guest. Unfortunately the graceful shutdown and restart options were grayed out which is a good indicator that the VMware Tools are not installed or not running. I logged into the VM and strangely enough, the VMware Tools were installed and the VMware Tools service was running. Even stranger, when I went back to the VIC, the VMware Tools status now showed “Tools OK”.

It was then that I noticed VMware Tools status was showing “Not Running” for a whole slew of other VMs which I knew had tools installed.

A quick search uncovered a recently updated VMware KB article 1008709VMware Tools status shows as not running after running VMware Consolidated Backup“. Mind you, I’m not running VCB in the lab (thank God and Veeam), however, the description in the KB article mostly matched my situation.

During the normal VMware Consolidated Backup (VCB) operation, the VMware Tools status changes from OK to Not Running for some time during the initial snapshot operation, but it returns to OK after the VCB operation completes.

However, on hosts installed with the patch bundle ESX350-200901401-SG, the VMware Tools status on the virtual machines may stay as Not Running even after the VCB operation completes.

Although the KB article specifically ties the problem to VCB, the problem is not limited to VCB in my experience. Other applications that perform snapshots can cause the behavior, such as the product I’m using: Veeam Backup 3.0. The root cause stems from a January 2009 VMware patch: ESX350-200901401-SG.

There are a few work arounds, the second of which I discovered on my own:

  1. Restart the mgmt-vmware service immediately after the backup job is done. This changes the Tools status to OK. You can write a cron job to do it periodically.OR
  2. Log in and log out, or log out if you are already logged in, from the virtual machine. This changes the Tools status to OK if it was showing as Not running.OR
  3. Use VCBMounter to look for virtual machine name or UUID rather than virtual machine IP. Virtual machine IP only works when the status of tools is OK, but virtual machine name and UUID works even if the Tools status shows as Not running.

After reading the KB article, I ran a service mgmt-vmware restart and after about a minute, the VMware Tools status for all my VMs changed in status from “Not Running” to “Tools OK”. The host and all of its VMs briefly disconnected as well but don’t worry, they’ll come back on their own shortly.

Until VMware releases a permanent fix, it sounds like I can expect this behavior daily after each Veeam backup completes.

By the way, if you’re running VCB, this condition will cause future VCB backups to fail if the VCBMounter is set to look for the virtual machine IP rather than virtual machine name or UUID. Nobody likes failed backups so please make sure you get this sorted out in your environment if the problem exists.

GuessMyOS plugin released

March 29th, 2009

Andrew the magnificent (vExpert Andrew Kutz of Hyper9) has unleashed a new plugin for the VMware Virtual Infrastructure Client called “GuessMyOS“.

System Requirements:

  • Microsoft Windows Installer 3.1
  • Microsoft .NET 3.5 (might as well install the SP1 version while you’re at it)
  • VMware Virtual Infrastructure Client

Andrew is the plugin Master. Now that he is officially and fully commissioned by Hyper9 to crank out cool stuff (instead of coding on his spare time), expect neato tools at a more consistent pace. I highly advise following his H9Labs RSS feed to stay up to date with his latest works:

Oh. What does it do? Remember VMware GSX Server and the web MUI where VMs were graphically represented by the guest OS thumbnail? That’s what it does, but now for ESX and ESXi. One thing you’ll notice is that in the Hosts and Clusters view, it displays the thumbnail in the left column, but not the main window pane on the right side of the screen. Same behavior in the Virtual Machines and Templates view. Maybe in the next version. Thanks a lot Andrew and keep up the great work! I can absolutely say that we live in a better VMware world with you in it.

3-29-2009 8-03-42 PM

Storage block size and alignment

March 20th, 2009

Steve Chambers posted version 2 of the Storage block size and alignment document over at the VIOPS (VMware Virtual Infrastructure Operations) site. At seven pages, it is both a short and a GREAT read.

For those not familiar with VMFS and VM guest alignment, I’ll summarize:

VMFS Alignment

  1. Unaligned volumes result in track crossing and additional I/O penalties in the form of latency and throughput which may or may not be noticeable in your environment (it depends)
  2. To verify whether or not your VMFS volumes are aligned, run the fdisk -lu command at the console
  3. VMFS volumes created with the Virtual Infrastructure Client (vSphere Client) are automatically aligned since it automatically align the volume along the 64KB boundary so no need to worry about the sub bullets in #2 above.
  4. NFS datastores are not concerned with VMFS alignment as they are not block VMFS datastores
  5. Alternatively, VMFS volumes can be aligned by following a series of fdisk commands manually which will destroy data on the volume (definitely not preferred)
  6. VMFS block size only determines maximum file size on the VMFS volume. VMFS block size does not play even a remotely significant performance role.  There are a number of expert blog articles which debate this.

VM Guest Alignment

  1. To verify whether or not your VM guest virtual disks are aligned, check the partition offset value
    • Aligned virtual disks will have a partition offset value evenly divisible by 4,096 (ie. 65,536 or 1,048,576 which is a default for Windows Server 2008)
    • Non-aligned virtual disks will have a partition offset value not evenly divisible by 4,096 (ie. 32,256 which is a default for Windows XP and Server 2003)
  2. Due to the destructive nature of the alignment procedures, alignment is always performed before data is placed on the volume
  3. Alignment in Linux guests is performed using an almost identical series of fdisk commands listed in a previous bullet
  4. Alignment in Windows guests is performed using diskpart.exe
  5. Although guest alignment is data destructive, guest alignment can be performed after the guest OS is installed because the document recommends that alignment of the OS partition is unnecessary; only align the data partitions before data is placed on them.  **see update below**

Alignment is most often going to be labor intensive and thus will have diminishing returns. This will especially be true if your environment has already been built and you need to align after the fact. Environments in the planning stages and not yet built will be among the best candidates for alignment right out of the gate. Whatever stage you are at, updating guest VM templates with alignment wouldn’t be a bad idea. Alignment of one image will pay dividends, whether noticeable or not, over and over as that template is deployed throughout the infrastructure.

Update: NetApp released a few scripts that will not only automate the verification and alignment processes at the guest VM OS level, the script will align the guest OS without destroying data. The one exception I ran into was with a Citrix VM that had remapped drives. CTXGINA.DLL got real cranky. The scripts are:

  • mbrscan - Scans the -flat.vmdk file for alignment
  • mbralign - Makes a backup of the .vmdk and creates a newly aligned .vmdk

See also:  NetApp – Storage Nuts & Bolts: mbrscan/mbralign

3-20-2009 1-24-50 PM

Other recommended reading:

Recommendations for Aligning VMFS Partitions

Performance Best Practices for VMware vSphere 4.1

Andrew Kutz joins Hyper9

February 28th, 2009

This news is a little over a week old but I just found out two nights ago while reading vExpert profiles and it’s definitely worth repeating.

Andrew Kutz is a recently named vExpert by VMware, Inc. and a well known developer in the VMware community. Andrew has authored a number of VirtualCenter plugins, of which the most famous might be his free Storage VMotion (sVMotion) plugin which provides VMware administrators a GUI interface to hot migrate VM storage from one LUN to another. Andrew has received well deserved praise for his work because he makes the lives of VI administrators easier.

Hyper9 is a startup company in Austin, TX that works in the virtualization infrastructure management space, developing tools that automate the management of virtualization in the datacenter. Hyper9 recently secured an additional round of investment funding and it would seem they are totally serious about delivering quality products to the virtualization community in the hiring of Andrew Kutz. What can we expect out of this? Given what I’ve seen from Andrew in the past, I’ll guess the future will be plugin based architecture which I think makes a lot of sense and is probably what the majority of the community wants.

Congratulations to both Andrew Kutz and Hyper9. I look forward to your accomplishments with great anticipation!

Read the official announcement from Hyper9 here.