Identifying orphoned virtual machines and hard disks in vSphere

Connect to the shell of the ESXi host system and browse to location of the datastore (/vmfs/volumes/{datastore name}) to which you want to identity orphoned virtual machine hard disks and invoke the following command. This will return all virtual machine hard disks to which the modified date is seven days in the past (-mtime +7) and return the filename pattern match (find -name “*flat.vmdk*) with the modified date timestamp (-exec stat -c “%n %y” {} \;).

find -iname "*flat.vmdk" -mtime +7 -exec stat -c "%n %y" {} \;

This approach assumes that if the virtual machine hard disk has not been touched in the specified timespan the virtual machine hard disk is orphoned. This may not be accurate, as the virtual machine may be in a powered off state for a period that exceeds the timespan and the virtual machine may be valid. The output should be similar to the below:

./vmfs/volumes/424b26ec-4294ea41/ubuntu-01/ubuntu-01-flat.vmdk 2017-01-29 10:52:03.000000000
./vmfs/volumes/424b26ec-4294ea41/ubuntu-02/ubuntu-02-flat.vmdk 2017-01-29 10:17:46.000000000
./vmfs/volumes/424b26ec-4294ea41/ubuntu03/ubuntu03-flat.vmdk 2017-01-29 11:04:18.000000000
./vmfs/volumes/424b26ec-4294ea41/ubuntu04/ubuntu04-flat.vmdk 2017-01-29 10:17:49.000000000
./vmfs/volumes/424b26ec-4294ea41/ubuntu05/ubuntu05-flat.vmdk 2017-01-29 10:52:03.000000000

An alternative method, is using RVTools which can identify orphoned virtual machines and hard disks (categorised as ‘zombie’) from the inventory scan of a vCenter Server System or ESXi Host System. On completion of the inventory scan, the vHealth tab will display any virtual machines and hard disks identified and may be exported for reference.

Component of the virtual machine is not accessible on the host when converting a template to a virtual machine

I was recently converting a template to a virtual machine for configuration when on performing the action to convert the template to a virtual machine using the vSphere Web Client I received the following error message:

A component of the virtual machine is not accessible on the host.

The cause of the above issue was due to due a component being attached to the virtual machine which was no longer available. in this case a virtual CD-ROM device connected to a Datastore ISO file. In order to resolve the issue I was required to modify the templates configuration file to remove the component that was no longer available. Firstly, from the vSphere Web Client I will remove the virtual machine template from the inventory and then connect to an ESXi host system which has access to the datastore to which the virtual machine is located using an SSH client.

Prior to modifying the configuration file, we will firstly create a backup of the configuration file in the existing folder in the event we need to roll back to the original configuration file.

cp /vmfs/volumes/54d9d092-5163b8c5-4ed9-5cf3fc946a28/deanvm1/deanvm1.vmtx /vmfs/volumes/54d9d092-5163b8c5-4ed9-5cf3fc946a28/deanvm1/deanvm1.vmtx.backup

Now we will be required to modify the configuration file using a text editor such, in this example ‘vi’.

vi /vmfs/volumes/54d9d092-5163b8c5-4ed9-5cf3fc946a28/deanvm1/deanvm1.vmtx

In this scenario we will need to modify the reference to the obsolete file being referenced and also modify the device type to the below and save the configuration file.

sata0:0.deviceType = "atapi-cdrom"
sata0:0.fileName = "

From the ESXi host system we will now register the virtual machine template, once the virtual machine template has been registered you will need to convert this from a virtual machine to a template using the vSphere Web Client.

vim-cmd solo/registervm /vmfs/volumes/54d9d092-5163b8c5-4ed9-5cf3fc946a28/deanvm1/deanvm1.vmx

Configure SNMP receivers on vCenter Server and ESXi Hosts

SNMP can be used to automatically retrieve status information from vSphere and ESXi hosts and provide the ability to push this information into a monitoring and management system.

You can configure a maximum of four SNMP receivers can be configured per vCenter to send SNMP traps to management systems.

To configure SNMP receivers, using the vSphere Web Client, select the vCenter server instance and browse to Manage > General > Edit > SNMP receivers.

You may also configure SNMP on a vCenter server using PowerCLI by invoking the ‘Get-AdvancedSetting’ and ‘Set-AdvancedSetting’ cmdlets, to which the Entity parameter is the vCenter server.

In order to retrieve the configuration for each SNMP receiver and to display the configuration parameter and value, we can invoke the following:

Get-AdvancedSetting -Entity deanvc1.dean.local -Name snmp.receiver.* | fl Description, Value, Description

If you required to target a specific SNMP receiver we can filter the name further, in the below example retrieving the configuration for SNMP receiver 2.

Get-AdvancedSetting -Entity deanvc1.dean.local -Name snmp.receiver.2* | fl Description, Value, Description

For a particular configuration parameter we can filer by the exact match of the name, where the below retrieves the community name for the primary SNMP receiver.

Get-AdvancedSetting -Entity deanvc1.dean.local -Name | fl Description, Value, Description

To configure the SNMP receiver using PowerCLI, we first need to retrieve the setting we require to modify and then pass this to the ‘Set-AdvancedSetting’ cmdlet to set the value, in this instance invoke the cmdlet without asking for user confirmation. In this example, we will configured the primary SNMP receiver with the community name ‘vmware’.

Get-AdvancedSetting -Entity deanvc1.dean.local -Name | Set-AdvancedSetting -Value vmware -Confirm:$False

A single SNMP receiver can also be configured on each ESXi host using ‘esxcfgcli system snmp’ from the command line interface. If we wish to retrieve the current configuration we can invoke:

esxcli system snmp get

The set of commands also allow for the SNMP receiver to be enabled,  set a community name and specify a target, as below:

esxcli system snmp set -enable true
esxcli system snmp set -communities vmware
esxcli system snmp set -targets deanesxi1.dean.local@161/vmware

Retrieving VM Affinity rules using PowerCLI

I was recently looking to retrieve output of various VM affinity rules for all clusters on a single vSphere server, I was able to retrieve this information using the Get-DRSRule cmdlet:

I need to invoke the cmdlet against all my clusters and to filter only to return DRS rules where the type is VM Affinity.

If (-not (Get-PSSnapin VMware.VimAutomation.Core -ErrorAction SilentlyContinue)) 
    Add-PSSnapin VMware.VimAutomation.Core
Connect-VIServer server.domain.local 
$DRSRules = Get-Cluster | Get-DrsRule | Where-Object {$_.Type -eq "VMAffinity"}

Now I have a set of DRS rules in a collection where the type is VM Affinity, I can now loop through each rule and return the information I require which in this instance is the below

  • DRS Rule Name
  • Cluster Name
  • Keep Together
  • List of VMs

We will now return this information, however in the default output the VM is referenced by the VMId and not the name, so in this isntance we will invoke the Get-View cmdlet agasint the returned VMId to retrieve the name.

ForEach ($DRSRule in $DRSRules)
    "" | Select-Object-Property @{N="Name";E={$DRSRule.Name}},
    @{N="VMs";E={((Get-View-Id $DRSRule.VMIds).Name)}}

A sample of the output for a single DRS rule is as below:

Name : Keep Virtual Machines Together
Cluster : Cluster1
KeepTogether : True
VMs : vm1, vm2, vm3

vSphere Inventory unable to connect to the remote server

I recently performed a search using the vSphere Client where I received the following warning message:


Quite a simple one to resolve in this instance, I checked the service ‘vCenter Inventory Service’ which was in a stopped state, starting the service resolved this issue and allowed for the return of the inventory search result without restarting the vSphere client