VMware Cloud on AWS is now available with two hosts deployment; starting from 33% cheaper

When VMware Cloud on Amazon AWS was introduced three years ago it required minimum of 4 hosts to be provisioned in production clusters. Then the requirement reduced to three hosts a bit later. They have now dropped one more host and the minimum requirements is two hosts now.

A few days ago VMware and Amazon AWS announced new upgrades in VMCA. Here are the key changes:

  • The minimum requirements for production cluster deployment reduced to 2 hosts. So the entry deployment cost is basically dropped by 33% that will attract small business.
  • Storage optimized AWS EC2 (I3en) instances are now available on VMCA for data-intensive with high random I/O workload such as Rational Database

While talking about VMware Cloud on AWS upgrades, I though it might be good to add basic information about VMware Cloud on Amazon AWS here:

  • VMware Cloud on AWS is basically VMware SDDC solution which is based on VMware Cloud Foundation platform with optimized access to native AWS services. VMCA run on elastic and dedicated hosts on Amazon AWS infrastructure
  • VMCA is currently available in 16 AWS regions. AWS is planning to expand the availability of VMCA to 21 regions by the end of the year
  • VMCA is a cloud choice for easily migrating VMs between on-premise VMware platform and cloud managed VMware SDDC platform that also provides integration to AWS services
  • VMware Cloud on AWS can be purchased either directly from AWS or APN partners
  • You can use your existing Windows Server licenses in VMCA. Consult your Microsoft product terms for any restrictions.
  • Each host is equivalent to an Amazon EC2 I3.metal instance (2 sockets with 18 cores per socket, 512 GiB RAM, and 15.2 TB Raw SSD storage).
  • Productions Clusters can have minimum 2 and maximum 16 ESXi hosts
  • Single host SDDC starter is a 30-days plan that can to reduce costs for proof of concepts
  • VMs can be moved (cold migrate) from on-premise DC with minimum version of vSphere 6.0 to VMCA
  • Hybric Link Mode is supported with vSphere 6.5 or later
  • Live migration can be done using vMotion or leveraging VMware Hyper Cloud Extension (HCX)

vSphere 6.7 General Support Extended

Previously the general support for vSphere 6.5 and 6.7 was full 5 years since the official release of vSphere 6.5 as 15 November 2021.

Earlier this month VMware has announced extension for General Support of vSphere 6.7. That means the general support for vSphere 6.5 remains as 15 November 20201 while it’s now extended to 15 October 2022 for vSphere 6.7.

This will allow the VMware customers to be able to keep their vSphere platforms in support while preparing for upgrading to vSphere 7.

VMware provides bug and security fixes, patches, upgrades and high priority (P1) technical support for customers on active general support.

Below is the End of General Support (EoGS) availability for vSphere

ProductGeneral AvailabilityEnd of General SupportEnd of Technical Guidance
vSphere 6.012 Mar 201512 Mar 202012 Mar 2022
vSphere 6.515 Nov 201615 Nov 202115 Nov 2023
vSphere 6.717 Apr 201815 Oct 202215 Nov 2023
vSphere 7.002 Apr 202002 Apr 202502 Apr 2027
vSphere Lifecycle Matrix

You might still get technical advice from VMware before EoTG if you have an active VMware support even if your vSphere version is out of general support. However you won’t be able to log high priority P1 tickets with VMware after EoGS.

In terms of licensing, there is no requirement for upgrading license keys if you are upgrading from 6.0 to 6.5 or 6.7 as they are all vSphere version 6.x. But if you are planning to upgrade to vSphere 7.0, the vSphere 6.x licenses won’t work on upgraded products and you will need to assign new Licenses.

I you have an active subscription and support with VMware then you can easily upgrade you vSphere licenses via myVMware portal. Otherwise check out the below link and check your license upgrade eligibility with VMware.


PowerCLI script to move a virtual disk between two VMs

    Move a virtual disk between two VMs

    Recently I was requested for writing a script to easily detach a virtual disk from a VM and attach it to another VM.

	2020/05/28 - 0.1 - Reza Rafiee		- Initial version


Write-host (" ")
$SourceVM = vRead-Host "Enter Source VM Name "
$srcVM=Get-VM -Name $SourceVM

Write-host ("The attached virtual disks on $srcVM.name ")
get-vm -name $srcVM | Get-HardDisk | Select Name,CapacityGB,Persistence,Filename

Write-host (" ")

$VDiskNumber =	Read-Host "Enter the Virtual Hard Disk Number that you want to detach from $srcVM.name  "

$VDiskSize = Read-Host "Enter the Disk Size (GB) "

Write-host (" ")

$TargetVM = Read-Host "Enter Target VM Name "

$trgVM= Get-VM -Name $TargetVM
$trgDisk="Hard Disk $VDiskNumber"

$disk=get-vm -name $srcVM | Get-HardDisk | Where-Object {($_.Name -eq $trgDisk) -AND ($_.CapacityGB -eq $VDiskSize)}

If ($disk -eq $null){
write-host ("No Hard Disk found as ($trgDisk - $VDiskSize GB) on $SourceVM")

$confirmation = Read-Host -Prompt "Are you sure you want to detach ($trgDisk - $VDiskSize GB) on $SourceVM and attach it to $TargetVM ? [y/n]"

If ($confirmation -eq "y") {
	Remove-HardDisk $disk -Confirm:$false
	New-HardDisk -VM $trgVM -DiskPath $disk.Filename
#You can also specify the SCSI controller of which the disk should be attached to by adding the following parameter to the above command:  -Controller "SCSI Controller 0"
	Write-host (" ")
	Write-host ("The attached virtual disks on $trgVM.name ")
	get-vm -name $trgVM | Get-HardDisk | Select Name,CapacityGB,Persistence,Filename

Connect vNIC on a VM to network using command line

Once upon a time I had an ESXi host in disconnected state and the management services were out of order and even restarting management services couldn’t help out to get it back to manageable state.

While the Host was partially manageable we had to connect a network interface of a VM to network but the only option was command line. The below commands did the job:

You will need to find the VM ID and the vNIC device ID as well using the below two commands:

vim-cmd vmsvc/getallvms | grep "VM_Name"
vim-cmd vmsvc/get.configuration "VM_ID"

Then you can run the below command to connect/disconnect the vNIC:

vim-cmd vmsvc/device.connection true|false


How to know if ESXi or Xen server is using UEFI or Legacy boot mode

There might be times that you need to know if the ESXi host boot mode is set to UEFI or Legacy and obviously one option is to reboot the host and check the boot mode from BIOS. But it requires a downtime and sometimes it’s not an option in critical production environment.

Here is a simple command in both ESXi and Xen server that you can run to identify the boot mode without rebooting the server:


to check boot type of esx run this command from putty SSH:

vsish -e get /hardware/firmwareType


to check boot type of a xen host check for the EFI folder under /sys/firmware/

open up the xen host console and run the check the contents of /sys/firmware folder by running the below commands:

cd /sys/firmware/

if it returns a folder labled EFI then it’s UEFI boot. Otherwise it’s Legacy.

Some useful tips for powering off VMs from ESXi Command Line

There might be occasions that you need to power off VMs from ESXi command line for some reason. knowing how to do it can save you time and effort from dealing with corrupted virtual disks and VMs. For instance an ESXi host loses all network connectivity due to a driver and firmware compatibility issue and you have to reboot the host but the VMs are still running with no network connectivity. In that case it will be safer if you gracefully shutdown the VMs and then put the host in maintenance mode and then reboot the ESXi host. Let’s see how to do it:

First of all you will need to grab Virtual Machines ID by running the below command:

vim-cmd vmsvc/getallvms

Below command returns the VM’s power state:

vim-cmd vmsvc/power.getstate VMID

Now you can try grcefully shutdown the VM. If the VM doesn’t respond to graceful shutdown in couple of minutes then you can forcefully power it off by the second command:

#For gracefull shutdown:
vim-cmd vmsvc/power.shutdown VMID
#For forcefully powering off the VM:
vim-cmd vmsvc/power.off VMID

The alternative way of doing the power off action is using ESXCLI command:

esxcli vms vm list
esxcli vms vm kill --type=[soft,hard,force] --world-id= WorldNumber

If neither of the above work then you will need to kill the VM process using below commands:

#find the VM World ID
esxcli vm process list

#Kill the VM process
esxcli vm process kill --type=[soft,hard,force] --world-id= WorldNumber

Note You can kill VM process using ps and kill commands similar to “esxcli vm process” if esxcli is not functioning.

Once you power off all you VMs then you can put the ESXi host in maintenance mode and power it off or reboot it using the following command:

#put the host in maintenance mode
esxcli system maintenanceMode set --enable true

#Power off the ESXi host
esxcli system shutdown [poweroff,reboot] --delay "seconds" --reason "description"

Compare Advanced Settings of two ESXi hosts

Of course you can use host profile templates to check compliance of ESXi host configuration against baseline configuration. But there might be some ad-hoc times that you need to compare Advanced Settings of two ESXi hosts and probably export a report out of it.

The below piece of PowerCLI code would be helpful for that purpose.

The credit for this code goes to Frederic Martin, the author of the code.

    This script will compare all advanced settings between 2 ESXi servers
    The script will compare each of all advanced settings between a source and a destination ESXi server and will display the difference
    Author     : Frederic Martin - www.vmdude.fr
.PARAMETER hostSourceName 
   Name of the host used for source compare
.PARAMETER hostDestinationName 
   Name of the host used for destination compare
   This switch allows you to bypass some advanced settings thanks to variable named $excludedSettings
	C:\foo> .\Compare-AdvancedSettings.ps1 -hostSourceName esx01.vmdude.fr -hostDestinationName esx02.vmdude.fr
	Display all differences between advanced settings from host esx01.vmdude.fr and host esx02.vmdude.fr
	C:\foo> .\Compare-AdvancedSettings.ps1 -hostSourceName esx01.vmdude.fr -hostDestinationName esx02.vmdude.fr -short
	Display differences (without those in $excludedSettings) between advanced settings from host esx01.vmdude.fr and host esx02.vmdude.fr

param (

# Checking if source host exists
if (-Not ($hostSource = Get-VMHost $hostSourceName -ErrorAction SilentlyContinue)) {
	Write-Host -ForegroundColor Red "There is no source host available with name" $hostSourceName

# Checking if destination host exists
if (-Not ($hostDestination = Get-VMHost $hostDestinationName -ErrorAction SilentlyContinue)) {
	Write-Host -ForegroundColor Red "There is no destination host available with name" $hostDestinationName

$diffAdvancedSettings = @()
# Using hastable for easy and fast handle
$advancedSettingsSource = @{}
$advancedSettingsDestination = @{}
# You can filter unwanted advanced settings to be unchecked (regexp)
$excludedSettings = "ScratchConfig.CurrentScratchLocation|ScratchConfig.ConfiguredScratchLocation|Vpx.Vpxa.config.vpxa.|UserVars.ActiveDirectoryPreferredDomainControllers|Config.Defaults.cpuidMask|Mem.HostLocalSwapDir"

# Retrieving advanced settings
Get-AdvancedSetting -Entity $hostSource | %{$advancedSettingsSource.Add($_.Name,$_.Value)}
Get-AdvancedSetting -Entity $hostDestination | %{$advancedSettingsDestination.Add($_.Name,$_.Value)}

# Browsing advanced settings and check for mismatch
ForEach ($advancedSetting in $advancedSettingsSource.GetEnumerator()) {
	if ( ($short -And $advancedSetting.Name -notmatch $excludedSettings -And $advancedSetting.Value -ne $advancedSettingsDestination[$advancedSetting.Name]) -Or (-Not $short -And $advancedSetting.Value -ne $advancedSettingsDestination[$advancedSetting.Name]) ) {
		$line = "" | Select Settings, SourceValue, DestinationValue
		$line.Settings = $advancedSetting.Name
		$line.SourceValue = $advancedSetting.Value
		$line.DestinationValue = $advancedSettingsDestination[$advancedSetting.Name]
		$diffAdvancedSettings += $line

# Displaying results

PowerCLI code to Find a datastore by NAA ID

There are times that you have a NAA ID of a LUN and need to find the corresponding datastore.

The below PowerCLI code is quite helpful that you can use to run to quickly find which datastore is attached to the NAA ID:

get-datastore |
Where-Object { $_.extensiondata.info.vmfs.extent.diskname -eq “NAA_ID of the Datastore”}

It returns the matching datastore name similar to this one:

get-datastore | Where-Object { $_.extensiondata.info.vmfs.extent.d
iskname -eq "naa.60060160f12335007e8600b99aeae211"}

Name                               FreeSpaceGB      CapacityGB
----                               -----------      ----------
DATASTORE_HIGH_0                       294.117       1,023.750

PowerCLI shortcode to find ESXi host using a Mac Address

There might be a situation that you need to look up an ESXi host with it’s Mac address especially when troubleshooting and tracing network connectivity issues.

Although you can use RVTools report to find the matching ESXi host but sometimes PowerCLI is just there and probably easier to run a single line code to grab the required information.

You can use the below single line PowerCLI to simply find which ESXi host owns the Mac address:

Get-VMHost | Get-VMHostNetworkAdapter | 
Where-Object {$_.Mac -eq "00:25:b5:01:00:1b"} | 
Select VMHost, Name, DeviceName, Mac

If there is an ESXi host in your vCenter environment that owns that Mac address then it will retrun the Hostname and the NIC name similar to the below:

VMHost                Name               Mac
------                ----               ---
ESXi01.mylab          vmnic9             00:25:b5:01:00:1b