Configure VM autostart in the ESXi Embedded Host Client

For a standalone ESXi host I manage the host with the ESXi Embedded Host Client (HTML client). So no vCenter Server is used to manage this host. The standalone ESXi host is 24×7 up and running and has some critical infrastructure VMs for my lab and home environment. The critical VMs are automatically powered-on when when the ESXi host is booted with the autostart option in the host client.

In the latest versions of the Host Client (In vSphere 6.7 version 1.25 is included that already contains the autostart improvements) the autostart configuration is greatly improved what result in an easier configuration of autostart. if you are on vSphere 6.0 or 6.5 I suggest to upgrade to the latest ESXi Embedded Host Client before configuring autostart.

The upgrade of the Host client is easy, no maintenance mode and reboot of the ESXi host is needed. The upgrade can be done by following these steps:

  • Download the latest VIB for here, link
  • Upload the VIB on a datastore on your ESXi host
  • SSH to the ESXi host
  • Enter the following command to update the host client
esxcli software vib update -v /vmfs/volumes/<datastore>/<vibname.vib>

  • Refesh the host client webpage (https://<esxihostname>/ui/)
  • Check the version information in the host client (Help -> About)

Configure autostart in the ESXi Embedded Host Client

  • Open the ESXi host client by using the following URL:  https://<esxihostname>/ui/
  • Go to: Manage -> System -> Autostart->Edit Settings
    • Enable: Yes
    • Start delay: 60 seconds
    • Stop delay: 60 seconds
    • Stop action: shut down
    • Wait for heartbeat: yes
    • Save

  • Below the screen are the VMs listed. First enable autostart per VM by using the “Enable  autostart for this VM” button.
  • Once the autostart is enabled per VM, the order can be configured by increase or decrease the start order. The autostart order is displayed in the “autostart order” field.
  • Configure the autostart and order for the VMs you want to automatically start when the ESXi server is booted.
  • Reboot the ESXi host to test the autostart

With older versions of the ESXi Embedded Host Client it is “more complicated” to set the start order per VM. To set the autostart order with older versions:

  • Enable autostart as described above

  • In the Virtual Machines section, right click on the  field row and “Select columns”. Select the following columns:
    • Autostart order
    • Start delay
    • Stop delay

  • Right click on the VM with the “Autostart order” status on Unset and select “increase” to enable autostart and set the order

  • Configure the autostart and order for the VMs you want to automatically start when the ESXi server is booted.
  • Reboot the ESXi host to test the autostart

vMotion between two vCenter Servers with different SSO domains

Last week i did my first vMotion between two vCenter Servers with different SSO domain by using PowerCLI. This functionality is also known as “cross vCenter vMotion” and is not included in the vSphere Web Client yet. Without downtime it’s possible to live migrate VMs from one vCenter Server to another. Cool stuff!

Before starting the following requirements must be met:

  • VMware vSphere 6.0 and later for the source and destination environment
  • PowerCLI 6.5 and later
  • vSphere Enterprise Plus license per ESXi host
  • An active connection to the source and destination  vCenter Server

I created a simple script to vMotion the VMs between the two SSO domains. See the more information section for more advanced PowerCLI scripts from for example William Lam and Romain Decker.

In the script the following variables must be defined:

  • Source vCenter Server, username and password
  • Destination vCenter Server, username and password
  • VM name will be moved
  • Destination vSwitch
  • Destination Portgroup
  • Destination datastore

Only VMs with one NIC are supported

PowerCLI example script

Import-Module VMware.PowerCLI
 
#Variables
$sourceVC = 'sourcevc'
$sourceVCUsername = 'administrator@vsphere.local'
$sourceVCPassword= 'password!'
 
$destVC = 'destinationvc'
$destVCUsername = 'administrator@vsphere.local'
$destVCPassword= 'password'
$destESXi = 'destinationesxi'
 
$vmname = 'vmname'
$Switchname = 'destinationswitch'
$NetworkName = 'destinationvlan'
$datastorename = 'destinationdatastore'
 
# Connect to the vCenter Servers
$sourceVCConn = Connect-VIServer -Server $sourceVC -user $sourceVCUsername -password $sourceVCPassword
$destVCConn = Connect-VIServer -Server $destVC -user $destVCUsername -password $destVCPassword
 
$vm = Get-VM $vmname -Server $sourceVCConn
$networkAdapter = Get-NetworkAdapter -VM $vm -Server $sourceVCConn
 
$destination = Get-VMHost -name $destESXi -Server $destVCConn
$destinationPortGroup = Get-VirtualPortGroup -VirtualSwitch $Switchname -name $NetworkName -VMHost $destination
$destinationDatastore = Get-Datastore -name $datastorename -Server $destVCConn
 
Move-VM -VM $vm -Destination $destination -NetworkAdapter $networkAdapter -PortGroup $destinationPortGroup -Datastore $destinationDatastore

With this script I migrated a couple of VMs between to vSphere 6.5 environment with different SSO domains without any downtime.

More information:

  • PowerCLI blog on the Move-VM cmdlet, link
  • William Lam, Automation Cross vCenter vMotion, link
  • Romain Decker Cross vMotion script from, link

What to know about VMware Cloud on AWS

At VMworld 2017 in Las Vegas VMware Cloud on AWS (VMConAWS) is announced. This partnership between VMware and AWS makes it possible to create a VMware Software Defined Datacenter (SDDC) in Amazon Web Services (AWS). In this blogpost  I highlight some information on “What is the VMware Cloud on AWS”.

  • VMware Cloud on AWS is a cloud service that is fully configured and will be provisioned, operated and maintained directly by VMware. VMware handles all patching and updates. As customer you manage the VMs, not the platform.

  • The following VMware products are included in VMware Cloud on AWS offering (compute, storage and networking):
    • vSphere ESXi on dedicated bare-metal hardware with support for VMs and containers
    • vCenter Server for management
    • vSAN All Flash storage
    • NSX for spanning on-premises and Cloud, advanced networking and security
    • vRealize products are NOT included in this offering but can integrated
  • In order for the on-boarding process to complete successfully there is a strict requirement that every organization be linked to an AWS account. Any services consumed within AWS will be billed through this Amazon account, while SDDC consumption will be billed through VMware.
  • The minimal purchase is cluster of 4 ESXi hosts. The maximum cluster size is 16 hosts.
  • It’s a dedicated platform that is not shared with other customers.
  • You can add additional on-demand hosts and also remove hosts on-demand down to 4 ESXi hosts.
  • Each ESXi host is has:
    • 2 pCPU sockets, 18 cores per socket = 36 cores total  and 72 with hyper-treading
    • 512 GB RAM
    • 14 TB NVMe RAW capacity storage (around 10 TB  of usable storage per host). In a 4 node cluster 21 TB of usable storage is available with FTT=1 (RAID=1) protection
    • The vSAN datastore is configured as a single datastore
    • 10 Gbps+ (ENA)
  • To extend storage you need to add extra ESXi hosts
  • The following VMware features are enabled:
    • vSphere HA,
    • vMotion,
    • DRS
    • Elastic DRS
  • Cluster functions are configured by VMware

  • It’s possible to connect the on-premises VMware datacenter with VMware Cloud on AWS by using for example  a L3 IPsec VPN and enable Hybrid Link Mode (HLM) between the two vCenter servers for single pane of glass hybrid cloud management.
  • In the future a Amazon direct connect is supported (1 Gbps or more)
  • There no need for NSX and vSAN in the on-premises datacenter.
  • Some use cases are:
    • Disaster Recovery (DR) and Backup.
    • Test and Development
    • Extend the on-premises data centers to the cloud with a consistent operational model, retaining your familiar VMware tools, policies and management.
    • New application development and test that access native AWS services
    • Burst capacity
  • On the moment the are two consumption models available:
    • On-demand/hourly consumption model
    • 1 or 3 years reserved model.
    • More on pricing can be found here, link
  • The initial release has support for cold migration. Cross cloud vMotion will be available in a future release
  • VMware Cloud on AWS is based on open API’s.
  • Currently VMware Cloud on AWS is only available in AWS US West (Oregon) region. Other regions will follow in 2018.
  • You can bring your own licenses because it’s a dedicated platform.

More information:

  • VMware Cloud on AWS website, link
  • VMware Cloud on AWS: Live End to End Demo, link
  • VMware on AWS from a Veeam perspective, link
  • VMware Cloud on AWS pricing versus on-premises vSphere, link