Archive for November, 2010

Ive come across the same problem at a number of customer sites recently, so I thought this might be something worth posting about.

The problem typically comes about as customers who’ve traditionally had vCenter running on a 32bit Operating System, now move to a x64bit Operating System to support vCenter 4.1 which enforces x64 bit architecture.

Now the actual root cause of the problem is the NetWorker 64bit client does not have the necessary nsrvim binary which is responsable for communicating with vCenter.

The good news is the fix is actually very simple, within the properties of the vCenter server youve configured in the NetWorker Management Console, just change the command host to any other networker system running a 32bit version of the client ( 7.5 and above ).

Typically the command host and the end point field have the same server configured, but as you can see from the screenshot below Ive just changed this to one of my test clients named “Client1”


Save the changes and away it goes again. Hope this helps.


Here’s the scenario,

  1. Using the Avamar management console, Add a Virtual Machine to the “Default Virtual Machine Group”
  2. Perform a Backup of the Virtual Machine
  3. Delete Virtual Machine using VI Client
  4. Perform a Virtual Machine Recovery back into Virtual Infrastructure
  5. Power Virtual Machine On
  6. Perform a Backup of the recovered Virtual Machine

I manually initiated a backup and saw the error shown below (A scheduled backup resulted in the error “NO VM“)

Because my NFS file systems are replicated I decided to perform a recovery back to a dedicated non replicated NFS datastore. At power on Virtual Center detects the Virtual Machine configuration file has moved and prompts with the following

This virtual machine might have been moved or copied.
In order to configure certain management and networking features, VMware ESX needs to know if this virtual machine was moved or copied.

If you don’t know, answer “I copied it”.
  • Cancel
  • I moved it
  • I copied it

I wasnt able to find anything on PowerLink about this, but I believe this is the root cause of the problem, Im always moving, copying and recovering Virtual Machines in the LAB and I’ve become accustom to selecting “I copied it” which generates a new UUID and before now have never had any problems.

I suspect when you add the Virtual Machine to Avamar it uses the UUID to track the VM as its common for VM’s to be renamed in vCenter. What I should have done is select “I Moved It” which results in the UUID being kept.

What I did to get around this was retire the Virtual Machine (choosing to keep the backup data based on retention) and then re-add the Virtual Machine again.

Backups were now successful.

I still need to do some more testing to confirm my suspicions around this being UUID related, but I would like to think that if this was the case, future versions of Avamar would let you update the configuration for situations where the Virtual Machine name stays the same but UUID changes.

I’ll update this post once I’ve confirmed.

Hidden VMware ThinApp License

Posted: November 2, 2010 in VMware View 4

I’ve been using a 140 day temp license for VMware ThinApp recently and today I thought it was time to go and grab my actual NFR license from the license portal but do you think I could find it ? – Nope.

I did consider that I may have had a man look (you know where you can’t find it and because it didn’t jump out at you, it’s obviously not there) but after a few looks I was certain I did not have the license for some reason.

It turns out that this is actually a known licensing issue and to quote the girl I spoke to in licensing support ” VMware are looking at resolving this in the future ”

To find the ThinApp license I had to click on the “Serial # Lookup” tab from the main licensing page and there is was listed as ” VMware Virtualization Packager “.