Automation – Page 166

VSAN Management 6.2 API Quick Reference

05.31.2016 by William Lam // 2 Comments

With the release of VSAN 6.2 (vSphere 6.0 Update 2), a new VSAN Management API has been introduced which covers all aspects of VSAN functionality including: complete lifecycle (install, upgrade, patch), monitoring (including VSAN Observer capabilities), configuration and troubleshooting. Although there is a well documented VSAN Management API Reference Guide which you can navigate around, I personally find it useful to be able to have a quick reference to all the APIs in on place which I can easily search and reference. This is especially true when I am learning about a new API.

With that, I have created a "Quick Reference" of the new VSAN 6.2 Management API. You can find a screenshot below as well as the direct link to the quick reference. I used Draw.io to create the diagram but it is not just a static image of all the new Managed Objects and their respective methods, but each API method also links back to the VSAN Management API Reference Guide and best of all, because it is in HTML, you can easily search in the quick reference itself.

I initially had created this for myself, but I figure that others could also benefit. I am curious if others find this useful and whether we should have something like this as part of the official VSAN Management API Reference Guide?

VSAN Management 6.2 API Quick Reference: https://s3.amazonaws.com/virtuallyghetto-download/vsanapi.html

Automating Cross vCenter vMotion (xVC-vMotion) between the same & different SSO Domain

05.26.2016 by William Lam // 79 Comments

In the last couple of months, I have noticed an increase in customer interests in using the Cross vCenter vMotion (xVC-vMotion) capability that was introduced back in vSphere 6.0. In my opinion, I still think this is probably one of the coolest features of that release. There is no longer the limitation of restricting your Virtual Machine mobility from within a single vCenter Server, but you can now live migrate a running VM across different vCenter Servers.

The primary method to start a xVC-vMotion is by using the vSphere Web Client which requires your vCenter Servers Servers to be part of the same SSO Domain and will automatically enable the new Enhanced Linked Mode (ELM) feature. ELM allows you to easily manage and view all of your vCenter Servers from within the vSphere Web Client as shown in the example screenshot below.

However, the vSphere Web Client is not the only way to start a xVC-vMotion, you can also automate it through the use of the vSphere API. In fact, there is even an "Extended" capability of xVC-vMotion that is not very well known which I have written about here which allows to live migrate a running VM across two different vCenter Servers that are NOT part of the same SSO Domain. This Extended xVC-vMotion (unofficially I am calling it ExVC-vMotion) is only available when using the vSphere API as the vSphere Web Client is unable to display vCenter Servers that are part of another SSO Domain. Below is a quick diagram to help illustrate the point in which VM1 can be seamlessly migrated between different vCenter Servers from within the same SSO Domain as well as between different vCenter Servers that are not part of the same SSO Domain.

Note: For additional details and requirements for Cross vCenter vMotion, please have a look at this VMware KB 210695 and this blog post here for more information.

UPDATE (06/15/17) - I have added a few minor enhancements to the script to support migrating a VM given a vSphere Resource Pool which enables the ability to migrate to and from VMware's upcoming VMware Cloud on AWS (VMC). There is also an additional UppercaseUUID parameter which seems to be required for some xVC-vMotions where the vCenter Server's InstanceUUID must be provided as all upper case or the operation will fail. I have still not identified why this is needed for some migrations, but for now there is a nice flag that can be used to enable this if you are hitting this problem.

UPDATE (04/08/17) - In vSphere 6.0 Update 2, there is a known limitation which prevents a VM that has multiple VMDKs stored across different datastores to be xVC-vMotion (compute only) using the vSphere Web Client. This limitation no longer exists in vSphere 6.0 Update 3 but does require customers to upgrade. If you need to perform a compute-only xVC-vMotion where the VM has multiple VMDKs across different datastores, the vSphere APIs does not have this limitation and you do not necessary need to upgrade to be able to perform this operation. Huge thanks to Askar Kopayev who discovered this and also submitted an enhancement to my xMove-VM PowerCLI script to support this functionality.

Given the amount of interest recently and some of the feedback on my original ExVC-vMotion script which I had written about here, I figured it was time to refactor my code so that it could easily support both ExVC-vMotion as well as standard xVC-vMotion. In addition, I have also added support for migrating to and from a Distributed Virtual Switch (VDS), where as previously the example only supported Virtual Standard Switch (VSS). Lastly, the script now also supports migrating a VM that is configured with multiple vNICs.

The new script is now called xMove-VM.ps1 and is even more simpler than my original script. You will need to edit the script and update the following variables:

Variable	Description
vmname	Name of the VM to migrate
sourceVC	The hostname or IP Address of the source vCenter Server in which the VM currently resides in
sourceVCUsername	Username to the Source vCenter Server
sourceVCPassword	Password to the Source vCenter Server
destVC	The hostname or IP Address of the Destination vCenter Server in which to migrate the VM to
destVCUsername	Username to the Destination vCenter Server
destVCpassword	Password to the Destination vCenter server
datastore	Name of the vSphere Datastore to migrate the VM to
cluster	Name of the vSphere Cluster to migrate the VM to
resourcepool	Name of the vSphere Resource Pool to migrate the VM to
vmhost	Name of the ESXi host to migrate the VM to
vmnetworks	Name of the vSphere Network(s). in the order in of the vNIC interfaces to migrate the VM to
switch	Name of the vSphere Switch to migrate the VM to that is comma separated and ordered by vNIC
switchtype	The type of vSphere Switch (vss or vds)
xvctype	Whether this is a Compute-only Cross VC-vMotion (1=true or 0 = false)
UppercaseUUID	There cases where the vCenter Server InstanceUUID must be all caps ($true or $false)

Here is a screenshot of running the script:

Note: When changing the type of vSphere Switch, the following combinations will are supported by the script as well as using the vSphere Web Client: VDS to VDS, VSS to VSS and VSS to VDS. VDS to VSS is not supported using the UI or API and neither are 3rd party switches supported.

Here are some additional xVC-vMotion and vMotion articles that may also useful to be aware of:

Customizing the ESXi DCUI to show number of VMs

05.24.2016 by William Lam // 7 Comments

Last week there was a question that was posted internally asking if it was possible to customize the ESXi DCUI screen to include the number of Virtual Machines? Although there is nothing out of the box, you can in fact add add almost anything to the DCUI screen by modifying the /etc/vmware/welcome configuration file which I had blogged about several years back on adding a splash of color to the ESXi DCUI. There was even a recent VMware Fling that provides a VIB that applies a variety of DoD STIG implementations, one of which was to update the DCUI screen with some specific text.

However, instead of having to manually edit the file directly on the ESXi host, we also provide an API in the way of an ESXi Advanced Setting called Annotations.WelcomeMessage which can then be updated remotely using anyone of the vSphere SDK/CLIs that you are familiar with.

Here is an example PowerCLI snippet to connect to an ESXi host (you can also do this by connecting to vCenter Server) and extracting all Virtual Machines residing on the host and then updating the DCUI screen with the total number of VMs as well as the names of each VM. Obviously, if you have more than 10 or so VMs, it may not make much sense to actually list them as it will just run off the screen, but this just gives you an example of some of the things you can do leveraging the vSphere API or any other data that you might have at your disposal.

Connect-VIServer -Server 192.168.1.50 -User root -Password vmware123

$vms = Get-View -ViewType VirtualMachine -Property Name

$DCUIString = "{color:yellow}
                {esxproduct} {esxversion}

                Hostname: {hostname}
                IP: {ip}
                
                Virtual Machines: " + $vms.Count + "
{/color}
{color:white}
"

foreach ($vm in $vms) {
    $DCUIString += "`t`t" + $vm.Name + "`n"
}

Set-VMHostAdvancedConfiguration -Name Annotations.WelcomeMessage -Value $DCUIString

Disconnect-VIServer -Confirm:$false

Note: If you wish to only filter out powered on Virtual Machines, you can add the following: -Filter @{"Runtime.PowerState" = "PoweredOn"} to the end of the Get-View command

Here is a screenshot quick screenshot of what this would look like on the DCUI screen of your ESXi host:

Note: You can actually run the DCUI over SSH, which can be useful for testing purposes without having to directly login to the console remotely. Take a look at this blog post here for more details.

One final thing to be aware of when editing the welcome message on your ESXi host is that it will also be displayed in the ESXi Embedded Host Client login page as shown in the screenshot below. Just something to be aware of in case you plan to make any sensitive information available as this can be seen without needing to login to the ESXi host (just like the DCUI interface).