Checked in the vCenter database for details on the plug-ins available. The table in question is [VPX_EXT_CLIENT], the field [EXT_ID] will tell you which plug-in each row refers to. In this case it is the com.vmware.converter row. Noticed that the [URL] field had spaces in it (the field read: http://:80/vmc/VMware Converter Client.exe). Changed the spaces to %20 (since this is a HTTP service) so the field read: http://:80/vmc/VMware%20Converter%20Client.exe), retried the download from vSpher Client, all worked well.

I figure the plug-in’s details were updated in the database when the Converter service was installed on the new vCenter service but not sure why it ended up like that. So, put the database entry back to it’s original format (i.e. spaces instead of %20’s) and went to another client that did not have the Converter plug-in installed. Interestingly, it could see the correct name and description and could download and install the plug-in…

This SRM implementation was using EMC RecoverPoint. To get the RecoverPoint SRA installed, SRM had to already be installed. However, couldn’t install SRM because it’s services would not start since the existing database it was connecting to expected the SRA to be available. Resolution was along the lines of the following:

*Make sure you have a backup copy of the database or use a temporary database (I used backup/restore method as opposed to a temp DB)*

1. Make sure the Site Recovery Manager Server service on the old server is stopped.
2. Backup the known good copy of the database
3. Run the SRM installer on the new 64-bit server, when prompted select the DSN (you created a 32-bit DSN, right?) to the existing database (choose to maintain the contents / do not overwrite)
4. Complete the installer
5. This is where it got funky. The Site Recovery Manager Server service fails to start so checked the logs located at %ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter Site Recovery Manager\Logs (open the current .log file)
6. The prompt at the installer will have the Retry and Cancel options. If you choose Cancel it will rollback the install and leave the database in an unhealthy state – this is where our backup is going to come in handy.
7. Once the rollback completes, start the install again and complete the exact same steps (this time it will not prompt you about overwriting the existing database as it doesn’t believe the database has vaild data). Allow the install to go through – it will finish this successfully this time.
8. Now, install the EMC RecoverPoint SRA. It will install successfully since SRM is now installed.
9. Uninstall SRM (just step through the uninstaller, don’t check the box about removing the database contents – not that it will matter as we will be restoring our known good copy anyway).
10. Restore the backup of the database choosing to overwrite the database.
11. Install SRM and this time it will prompt regarding the existing database – select to use the existing database.
12. The installer will still fail this time as well, but checked the log this time and found the following:

[2010-08-26 15:34:40.560 03192 verbose 'PrimarySanProvider'] Loading Array Manager 'array-manager-4353' from DB object
[2010-08-26 15:34:40.560 03192 warning 'DrServiceInstance'] Initializing service content: (dr.san.fault.ManagementSystemNotFound) {
   dynamicType = ,
   faultCause = (vmodl.MethodFault) null,
   name = "C:/Program Files/VMware/VMware vCenter Site Recovery Manager/scripts/SAN/array-type-recoverpoint",
   msg = "",
}
[2010-08-26 15:34:40.560 03192 error 'App'] Application error: dr.san.fault.ManagementSystemNotFound. Shutting down ...
[2010-08-26 15:34:40.560 01788 info 'App'] [serviceWin32,421] vmware-dr service stopped

13. The problem here is that the old server was 32-bit windows and therefore installed everything to C:\Program Files\… but our new server is 64-bit and SRM installs to C:\Program Files (x86)\…
14. The array manager script path is actually stored in the database. Find the table [pds_arraymanagere] and update the field [scriptpath] to reflect the correct (x86) directory.
15. Hit Retry and the service should start correctly.

Still needed to re-pair the sites in SRM but this was the biggest hurdle in migrating the server. Also, reading that process back, the whole thing could have been done in a few different ways.Anyway, this was a bit of a worst case scenario but ultimately it worked out well.
Note: This KB article does exist, bubt it is for two specific scenarios as hihlighted in the article, not this situation

Connect-VIServer vcenter-server.domain.com
$vms = Get-VM
$mybool = $False
foreach ($vm in $vms){
$snap = Get-Snapshot -VM $vm
if ($snap){
$mybool = $True
Write-Host "VM Name: " $vm.Name " Snapshot Name: " $snap.Name " Created: " $snap.Created
}
}
exit

In the above code the $mybool variable is used to keep track if any VM’s have snapshots or not. The purpose of this code was to send an email if any VM’s had snapshots. So, you could replace Write-Host with a string variable and write the output to that then send it via email to alert someone. You can also use the $snap.Size property to determine how big the VM’s snapshots have grown which is a good indicator on how long it will take to commit them back the the parent disk, if that is your aim.

Again, the situation is VCB failing to remove the snapshot it took of a VM when the backup job that kicked it off failed (because of lack of disk space in this case).

First, vcbSnapshot was used to try and remove it via the VCB proxy manually. For one reason or another, this failed and a Consolidate Helper- 0 snapshot is left behind. In the VI Client, it will show no snapshots in Snapshot Manager but a check of the VMDK targets show that the VM is indeed pointing to delta disks.

Tried taking a new snapshot manually to confirm the .vmsd file is not corrupt. The chain appeared good. Used:
vmare-cmd .vmx removesnapshots
and received the error:
unable to access file since it is locked

While looking into the problem, found these excellent resources for the undocumented vmkfstools -D switch which dumps file info to /var/log/vmkernel. It can be used to identify the owner of a file lock which could be causing the above error when trying to commit back the snapshot delta files:

http://vi3.org/download/guides/english/vi3/StoppingaVMandReleasingFiles.pdf
http://blog.core-it.com.au/?p=477

In this case, however, I didn’t go through the process – instead took the coward’s way out and used: service mgmt-vmware restart on the host that the VM was running on and then used vmware-cmd to commit the snapshots – worked fine this time.

So, I would expect that if I had used the -D switch on the VMDK’s attached to the VM, the owner would have eventually been the ESX Host Agent which would be locking the file on behalf of the VCB request. Must remember to go through the process next time to find out for sure…

Since data protection vendors are starting to release vStorage API for Data Protection products (Veeam Backup & Replication, Symantec NetBackup 7), VCB would likely begin to be phased out in many environments. Not that the vStorage API is a replacement for VCB as such, but it could be a good fit in many environments.