The following will get CPU (num of cores) counts from hosts and will also get vCPU counts from VM’s. It will also get the operating system of each VM, its power state and the average CPU for the past week. The end of each section also has a count of the number of objects (hosts and VMs) in the environment.

Connect-VIServer <Your_vCenter_Server>
# define start and finish days (1 week period)
$startdate=(get-date).addDays(-7)
$finishdate=(get-date).addDays(-1)
# initialise counters
$vmcount=0
$hostcount=0

ForEach ($esxhost in (Get-VMHost | Sort Name)){
	Write-Host $esxhost.Name","$esxhost.NumCPU
    $hostcount++
}
Write-Host "Total Hosts:" $hostcount

ForEach ($vm in (Get-VM | Sort Name)){
    If ($vm.PowerState -eq 'PoweredOn'){
        $vstats = (Get-Stat -entity $vm -stat cpu.usage.average -Start $startdate -Finish $finishdate | measure-object -property value -average)
        # round to two decimal places
        $vavg = [system.math]::round($vstats.average,2)
    }Else{
        $vavg = 0
    }
	Write-Host $vm.Name","$vm.Guest.OSFullName","$vm.PowerState","$vm.NumCPU","$vavg
    $vmcount++
}

Write-Host "Total VM's:" $vmcount

This is a digital mental note of where VMware Tools can be downloaded from

http://www.vmware.com/download/packages.html

or direct to the tree:

http://packages.vmware.com/tools/index.html

Also, this is my 50th post. Woohoo! A ridiculous rant might have to wait until the 100th post. Yeah, that makes sense.

Was getting error “Unable to Connect to Remote Server” when trying to install the Converter plug-in from vSphere Client. The plug-in name and description were also appearing as just “converter” as opposed to “vCenter Converter” as it should be. The vCenter server had been recently setup and connected to an existing database which previously had Converter installed and the plug-in available from vCenter.

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:/server:80/vmc/VMware Converter Client.exe). Changed the spaces to %20 (since this is a HTTP service) so the field read: http:/server:80/vmc/VMware%20Converter%20Client.exe), retried the download from vSphere 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…

Followed this KB article on migrating an existing SRM instance to a new server. A few hiccups, however.

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

Because it’s a pain to check all VM’s for outstanding snapshots from the VI Client, this script is useful for listing any VM’s that have outstanding snapshots and when they were created. Referenced mostly from here [vSphere PowerCLI Blog]

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.