Set Mime Type for Resource Element in vRealize Orchestrator

A resource element allows for the use of external objects as attributes in workflows created independently of vRealize Orchestrator. For example, items such as JSON templates.  By importing the external object as a resource element allows for changes to the object and for those changes to be propagated to all workflows that use the resource elements.

When importing the external object as a resource element, the mime type is set from the content of the external object. In some instances, the mime type maybe incorrectly set during the initial import of the external object as a resource. So how do you we update this to be the correct type?

Unfortunately this is not available from vRealize Orchestrator UI, so for my use case I created a module action that will allow for the mime type to updated and set to the correct type. The module action requires for the resource element and the mime type to be specified as input parameters. For a valid list of mime types, refer to Basics of HTTP – Mime Types

In this instance I am going to run the workflow that executes the module action, to set an existing resource element that has been previously imported named ‘Test Resource Element.json’ which has the mime type set to ‘application/octect-stream’ to a mime type of ‘text/plain’.

Following successful execution of the workflow, we can confirm that the mime type of the resource element has now been updated to ‘text/plain’ as per the console log output from the mime type of the resource element.

[2017-09-13 17:19:21.130] [D] The resource element Test Resource Element.json has been returned with the mime type application/octet-stream
[2017-09-13 17:19:21.156] [I] The resource element Test Resource Element.json mime type type has been set to text/plain

The package which contains the module action and workflow item is available at com.deangrant.library.vro

Advertisements

Return REST host by name from vRO HTTP-REST Plug-in

The HTTP-REST Plug-in allows for the interaction between vRealize Orchestrator (vRO) and REST hosts by defining services and their operations as inventory objects. When creating a workflow to remove the requirement to specify the REST:RESTHost type object as input parameter, I prefer to discover and return the type object by name this is particularly useful when executing a workflow to which the inventory object is determined by decision logic. The actual name of the inventory object in this example may be enumerated from a resource element or from a call to the configuration management database (CMDB).

The HTTP-REST plug-in exposes Javascript API classes related to REST object management and contains methods related to CRUD operations for REST hosts. In order to return a specified REST:RESTHost from the RESTHostManagerClass, the method ‘getHost(String):RESTHost’ allows for a REST:RESTHost to be returned from the plug-in’s inventory.

The following module action requires the name of the REST:RESTHost object specified as an input parameter. A collection of REST:RESTHost objects will be returned from the RESTHostManager class from the plugin’s inventory and return the REST:RESTHost type object from the associated object identifier as a string, a match will then be performed on the specified name from the input parameter and if true return the REST:RESTHost type.

The package which contains the module action and workflow item is available at https://github.com/dean1609/vRO/tree/master/com.deangrant.http.rest.

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.

vCenter Server 5.5 Update 3a: Update fails with Warning 32014.

Recently during an upgrade of a an instance of a vCenter Server System to 5.5 Update 3a the installation returned an error with the following message:

Warning 32014. A utility for phone home data collector couldn’t be executed successfully Please see its log file (with name PhoneHome) and vminst.log in system temporary folder for more details.

Upon restarting the ‘VMware VirtualCenter Server’ service the following error message is returned:

Error 1053: The service did not respond to the start or control request in a timely fashion.”

This is a known issue affecting vCenter 5.5 where the installer failed to update the ‘deployPkg.dll’ file during the upgrade process, to which currently there is no resolution.

To workaround the issue we have two options. Firstly, we can rollback the instance of the vCenter Server System prior to the upgrade and remove the file from patch cache which by default is located at ‘C:\Windows\Installer\$PatchCache$\Managed\05550F1E83248734780F0115742A159D\5.5.0’ and perform the upgrade.

Alternatively, you can perform the following to provide resolution to the issue.

1) Browse to ‘C:\Program Files\VMware\Infrastructure\VirtualCenter Server\’ and remove the file ‘deployPkg.dll’.

2) Download the file ‘2134141_deployPkg.zip‘ from the official VMware site and extract to the location ‘C:\Program Files\VMware\Infrastructure\VirtualCenter Server\’.

3) Start both the ‘VMware VirtualCenter Server Service’ and ‘VMware VirtualCenter Management Webservices’ services.

4) Uninstall the Profile-Driven Storage service by running the following command with elevated privelages.

msiexec.exe /x {7BC9E9D9-3DF6-4040-B4A1-B6A3A8AE75BA} SKIPVCCHECK=1 SUPPRESS_CONFIRM_UNINSTALL="1" /qr

5) Install the vCenter Server 5.5 Update 3a version of the Profile-Driven Storage by running the following command with elevated privelages. In the below example, I am using ‘vcenter.dean.local’ as the FQDN of my vCenter Server System and the installation media is mounted on D:\.

msiexec.exe /L*V "%temp%\sps_vminst.log" /I "D:\vCenter-Server\Profile-Driven Storage\VMware vSphere Profile-Driven Storage.msi" INSTALLDIR="C:\Program Files\VMware\Infrastructure\" COMPUTER_FQDN=vcenter.dean.local TOMCAT_MAX_MEMORY_OPTION="S" VC_KEYSTORE_TYPE=PKCS12 VC_KEYSTORE_PASSWORD=testpassword VC_SSL_DIR="C:\ProgramData\VMware\VMware VirtualCenter\SSL\" VC_SPS_EXTENSION_DIR="C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions\com.vmware.vim.sps\" IS_URL="https://vcenter.domain.local:10443" ARPSYSTEMCOMPONENT=1 SKIPVCCHECK=1 /qr

Now confirm that all your services are running and you are able to access the vCenter Server System.

As this is a known issue, you can prevent the symptom of this prior to performing an upgrade by removing the file from the patch cache prior to running your vCenter Server System upgrade.

Consolidating unmounted and open snapshots after virtual machine backup

At times, one or more disks from a virtual machine will remain mounted and snapshots will remain following the backup of a virtual machine. The cause of this is generally due to their not being enough time to unmount the disks and consolidate the snapshots when the job completes.

This would require user interaction to firstly unmount the virtual machine disks and then perform a consolidation of the virtual machine virtual disks. As we can agree, this is a manual task that is perfect to be automated.

The below solution has a number of caveats, the backup solution/appliance is a virtual machine and the virtual machine contains no hard disks that are of the disk type ‘Independent – Nonpersistent’.

The script in its entirety can be downloaded from here. However, the below will describe the logic to remove the virtual machine hard disks and consolidate the virtual machines.

Once we have established a connection to the vCenter Server and specified the virtual machine running the backup appliance/solution we will retrieve a collection of virtual machines where the ‘RunTime.ConsolidatedNeeded’ value is equal to ‘True’.

$VMs = Get-View -ViewType VirtualMachine -Property Name, RunTime | Where-Object {$_.RunTime.ConsolidationNeeded -eq $True}

Then we will connect to the virtual machine hosting the backup appliance/solution and retrieve all the virtual machine hard disks where the persistence value is equal to ‘IndependentNonPersistent’.

$HardDisks = Get-VM $ComputerName | Get-HardDisk | Where-Object {$_.Persistence -eq 'IndependentNonPersistent'} 

We will then invoke the Remove-HardDisk cmdlet to remove the filtered virtual machine hard disks. In this instance we are only removing the hard disks and not deleting them permanently.

Get-HardDisk -VM $ComputerName -Name $HardDisks.Name | Remove-HardDisk -Confirm:$False

Once the virtual machine hard disks have been removed, we will now consolidate the virtual machine disks on each of the virtual machines returned in the collection.

(Get-VM $VM.Name).ExtensionData.ConsolidateVMDisks() | Out-Null

The above script will provide console output to report the status of the invocation and can be triggered as a scheduled task returning an exit return code dependant on the status of the invocation.

PowerCLI: Retrieving ESXi Host System Management Network IP Address

I was recently looking at retrieving the allocated management network IP address for a large number of ESXi host systems and therefore decided to use the ‘Get-VMHostNetworkAdapter’ cmdlet  to which I would filter based on the device name value retrieved from the ESXi host system. In its simpliest form the cmdlet can be invoked as below:

Get-VMHostNetworkAdapter -VMHost esxi1.dean.local

In this instance I wanted to retrieve only the allocated IP address to the device name vmk0 (management network) for all ESXi host systems in a datacenter, which could be achieved by invoking the cmdlet with the filter to retrieve only the host network adapter where the device name was equal to ‘vmk0’

Get-Datacenter Edinburgh | Get-VMHost | Select-Object @{N="Name";E={$_.Name}},@{N="Management Network";E={(Get-VMHostNetworkAdapter -VMHost $_.Name  | Where-Object {$_.Name -eq "vmk0"}).IP }}

As the above retrieved both the name of the ESXi host system and the allocated IP address of the management network this provided me with the information required. However, in the future would I need to repeat this task with the same or different requirements. Therefore I decided to create a function which would retrieve the management network IP address for a filtered list of ESXi host systems to which this could be targeted at a vCenter Server System, Datacentre, Cluster or a particular list of ESXi host systems., as below.

The function will establish a connection to the vCenter Server System retrieve a collection of ESXi host systems as specified or retrieve a collection of all ESXi host systems managed by that vCenter Server and return the host name and management network IP address.

Function Get-VMHostManagementNetwork { 

Param ([Parameter(Mandatory=$true)][String[]] $VIServer,[String[]] $Datacenter,[String[]] $Cluster,[String[]] $VMHost) 

If (-not (Get-PSSnapin VMware.VimAutomation.Core -ErrorAction SilentlyContinue)) {Add-PSSnapin VMware.VimAutomation.Core | Out-Null}

Connect-VIServer $VIServer | Out-Null 

If ($Datacenter){$VMHosts = Get-Datacenter $Datacenter | Get-VMHost} 
ElseIf ($Cluster) {$VMHosts = Get-Cluster $Cluster | Get-VMHost} 
ElseIf ($VMHost) {$VMHosts = Get-VMHost $VMHost} 
Else {$VMHosts = Get-VMHost}

$VMHosts | Select-Object @{N="Name";E={$_.Name}},@{N="Management Network";E={(Get-VMHostNetworkAdapter -VMHost $_.Name  | Where-Object {$_.Name -eq "vmk0"}).IP }}
} 

The PowerShell function can be downloaded from here.

Installing open-vm-tools deployPkg plug-in for Ubuntu Guest Operating Systems

If you are installing the open source implementation of VMware Tools ‘open-vm-tools’ into your guest operating system and require to use the virtual machine as a template or leverage Site Recovery Manager to customize virtual machines after failover, then there is a requirement to install the ‘deployPkg Tools’ plug-in.

The below details installing the plug-in on an Ubuntu operating system, however steps for other operating systems can be found here.

Firstly, we will need to obtain and import the VMware Packaging Public keys which can be downloaded from here and the files are required to be saved into a directory on the guest operating system.  For each key downloaded, we will import the key on successful completion you should receive the below notification:

sudo apt-key add /tmp/keys/VMWARE-PACKAGING-GPG-DSA-KEY.pub
OK
sudo apt-key add /tmp/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub
OK

We will now create the file ‘/etc/apt/sources.list.d/vmware-tools.list’ to add the below package repository and update the package index.

deb http://packages.vmware.com/packages/ubuntu precise main
sudo apt-get update

Once the package index has been updated we can invoke the following to install the ‘deployPKG’ plug-in. Once installed you should be able to customize your template or virtual machine for failover using Site Recovery Manager.

sudo apt-get install open-vm-tools-deploypkg