WilliamLam.com

New Instant Clone Architecture in vSphere 6.7 - Part 1

by // 6 Comments

Instant Clone or VMFork (as it is referred internally) has been around for a number of years now. It was initially available as part of vSphere 6.0 with the primary consumer being Horizon View and their just-in-time desktop solution. Although Instant Clone was part of the core vSphere platform, public APIs were not available for external consumption. Many customers were interested in the technology to enable other non-VDI use cases such as Dev/Test, Continuous Integration/Continuous Development (CI/CD) and even Container workloads. Part of the reason for not exposing the API was partially due to the original Instant Clone architecture which has certain limitations and constraints.

In addition, VMware was also interested in getting feedback from customers on how they would like to consume Instant Clone from an Automation standpoint, this was important because the current workflows were also some what complex. This started out with the release of a PowerCLI Instant Clone Extension Fling that provided an abstraction on top of the private APIs. Based on that and other feedback, VMware followed that up by releasing Instant Clone for pyvmomi (vSphere SDK for Python) Fling which gave customers more programmatic access to the private APIs. Both Flings were a huge success and we even had customers using the pyvmomi Instant Clone modules in Production to deploy several hundred Instant Clone VMs per day for their CI/CD workloads.

Taking the learnings from both Horizon View and the feedback from customers using the Flings, the Instant Clone Product/Engineering team has been hard at work behind the scenes on simplifying the Instant Clone architecture and removing limitations and constraints that had existed in earlier versions. As you can imagine, this was a non-trivial amount of work that would need to be released in phases, especially as VM lifecycle management touches almost every part of the vSphere stack. The team really focused on ease of consumption, especially from an Automation standpoint which is how most customers prefer to consume Instant Clone.

[Read more...]

New vSphere 6.7 APIs worth checking out

by // 3 Comments

Below are just a few of the new vSphere 6.7 SOAP and REST APIs that have been added or enhanced which I think will be quite useful for customers to be aware of while they start to plan for their vSphere 6.7 upgrades. For a complete list of new vSphere 6.7 (SOAP based) APIs, check out the vSphere 6.7 API Reference Guide which will include a "What's New" section on all the new Managed Objects, Methods, Properties, etc. For a complete list of new vSphere 6.7 REST based APIs, check out vSphere Automation API 6.7 Reference which you can identify new operations and properties which will be marked with "Added in vSphere 6.7".

vSphere 6.7 WebServices (SOAP) API

AlarmManager->ClearTriggeredAlarms() - This method finally provides a way for customers to clear an alarm like you can using the vSphere UI. Historically, customers only had the ability to acknowledge an alarm using the API but not a way to reset alarms.

VirtualMachine->ApplyEvcModeVM_Task() - This method can be used to enable the new Per-VM Enhanced vMotion Capability (EVC) feature that has been introduced in vSphere 6.7

VirtualMachine->InstantClone_Task() - This method simplifies the deployment of new version of Instant Clone that has been added into vSphere 6.7. For more details on how the new Instant Clone feature works, please take a look at this blog post here.

HostNvdimmSystem - This new Managed Object and its respective methods can can be used to manage the new NVDIMM (Persistent Memory) capability that has been added into vSphere 6.7

VirtualMachine->Config->createDate - This new property finally includes the creation date of a VM that has been created in vSphere 6.7 and will be persisted with the lifecycle of the VM itself. I will provide a more detailed blog post on how to consume this new property as well as the expected behaviors, especially around upgrades. I know many of you have been asking for this property and I am glad to see this finally available for all on-premises customers!

VirtualMachine->Flags->vbsEnabled - This new property allows customers to easily enable the new Microsoft Virtualization-Based Security (VBS) feature which was added in vSphere 6.7. This single property (UI/API) behind the scenes actually enables a number of other VM settings required for VBS to properly run such as Virtual Hardware Virtualization (VHV), vIOMMU, EFI Firmware & Secure Boot, which is nice as customers do not have to worry about the underlying settings and simply toggle a simple boolean property.

VirtualMachineGuestOsIdentifier - These are all the new GuestOS Ids that have been added into vSphere 6.7 to enable new GuestOS support, you can find the mapping of the OS type by taking a look at the vSphere API Reference Guide

  • asianux8_64Guest
  • centos8_64Guest
  • darwin17_64Guest
  • darwin18_64Guest
  • freebsd11Guest
  • freebsd11_64Guest
  • freebsd12Guest
  • freebsd12_64Guest
  • oracleLinux8_64Guest
  • other4xLinux64Guest
  • other4xLinuxGuest
  • rhel8_64Guest
  • sles15_64Guest

vSphere 6.7 REST API

/appliance/backup/schedules - This endpoint provides management and configuration of the new VCSA scheduled backup feature

/appliance/backup/system_name - This endpoint allows you to list all existing backups that have been taken for your VCSA

/appliance/local_accounts - This endpoint provides management of all local users

/appliance/local_accounts/policy - This endpoint provides global password policy management for all local users

/appliance/logging/forwarding - This endpoint provides external syslog configuration for the VCSA

/appliance/networking/proxy - This endpoint provides HTTP(S) proxy configurations for the VCSA

/appliance/ntp - This endpoint provides NTP configuration for the VCSA

/vcenter/deployment - This endpoint enables the ability to automate both Install/Upgrade of the Stage2 installer for VCSA/PSC. Stage 1 deployment of the appliance is currently not part of the REST API but can be automated using existing methods such as OVFTool or PowerCLI as an example.

/vcenter/vm/guest/{identity,local_filesystem} - This endpoint provides guestOS details such as the configured OS along with some basic networking (e.g. Hostname and IP Address) which is retrieved as part of the VMware Tools service running inside of the GuestOS. In addition, you can also get visibility into the guest filesystem including capacity and freespace.

/vcenter/vm/storage/policy - This endpoint provides details about the current configured VM Storage Policy for individual VMDKs of a VM

Identifying ESXi boot method & boot device

by // 13 Comments

There was an interesting discussion on our internal Socialcast platform last week on figuring out how an ESXi host is booted up whether it is from local device like a disk or USB device, Auto Deploy or even boot from SAN along with its respective boot device? Although I had answered the question, I was not confident that we actually had a reliable and programmatic method for identifying all the different ESXi boot methods, which of course piqued my interest.

With a bit of trial and error in the lab, I believe I have found a method in which we can identify the ESXi boot type (Local, Stateless, Stateless Caching, Stateful or Boot from SAN) along with some additional details pertaining to the boot device. To demonstrate this, I have created the following PowerCLI script ESXiBootDevice.ps1 which contains a function called Get-ESXiBootDevice.

The function can be called without any parameters, in which it will query all ESXi hosts for a given vCenter Server and/or standalone ESXi host. You can also specify a specific ESXi host by simply passing in the -VMHostname option.

Here is an example output for one of my lab environments which shows several ESXi hosts and their different boot methods from local disk to Auto Deploy which can include stateless, stateless caching and stateful deployments. Depending on the BootType, the boot device shown in the Device column will either be the MAC Address of the NIC used to network boot the ESXi host or the identifier of a disk device. I have also included some additional details such as vendor/model along with the media type (SAS, SSD or USB) which is available as part of ESXCLI.


This script also supports ESXi environments that boot from SAN (FC, FCoE or iSCSI) and you can easily identify that with the word "remote" for the BootType. I would like to give a huge thanks to David Stamen who helped me out with the boot from SAN testing.