WilliamLam.com

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

VMware Tools 10.2.0 enables Virtual Machine vNIC exclusion and priority re-ordering

by // 8 Comments

VMware Tools 10.2.0 just GA'ed (release notes / download and open-vm-tools release notes / open-vm-tools download) and this release includes a number of new features like an offline bundle for VMware Tools VIB for ESXi and support for deploying VMware Tools using Microsoft System Center Configuration Manager (SCCM) to just name a few. There are also two additional new capabilities that I wanted to share as I think customers can benefit from and take advantage of immediately around how Virtual Machine vNICs are displayed. One of the challenges with having the broadest Guest Operating System (GOS) support in vSphere is dealing with some of the different behaviors of each GOS. One such example are the various ways in how both physical and logical networks interfaces are enumerated by an OS.

Take the example below, I have a PhotonOS VM which has eth0 as the primary interface and it is configured with an IP Address of 192.168.30.101. However, as you can see from the screenshot below I am actually getting back a different address and interface. In addition to this, we also see other logical interfaces showing up in the IP Address list such as Docker interfaces as well as virtual and other pseudo interfaces that may or may not be useful to VI Admins.


Historically, there was not a way to control what would show up in the network interface list which is then propagated from VMware Tools up to both the vSphere API as well as vSphere UI. With this new release of VMware Tools, which can be applied asynchronously to a given vSphere release, customers now have the ability to filter on a per-VM basis on what interfaces actually show up as well as a relative priority for interfaces that customers care more about.

[Read more...]

Enabling shell access for Active Directory users via SSH to vCenter Server Appliance (VCSA)

by // 5 Comments

I had a question the other day on whether it was possible to enable shell access for Active Directory users when logging into the vCenter Server Appliance (VCSA) via SSH? The answer is yes and though this is documented here, it is not very clear whether this is only applicable to SSO-based users only. In any case, the process to enable this is pretty straight forward and simply requires two steps which I have outlined below.

Step 0 - Ensure that your VCSA and/or PSC is joined to Active Directory before proceeding to the next step. If not, take a look at the documentation here for more details.

Step 1 - Login to vSphere Web Client and under Administration->System Configuration->Nodes->Manage->Settings->Access, go ahead and enable boh SSH and bash shell options. The first setting turns on SSH to the VCSA and the second setting allows users (local, SSO and AD) to access the shell on the VCSA.


Step 2 - In the vSphere Web Client and under Administration->Single Sign-On->Users and Groups->Groups, select the SystemConfiguration.BaseShellAdministrators group and add either an AD User and/or Group that you wish to allow to access the shell.


Once you have completed the steps above, you can now SSH to your VCSA/PSC using the AD user (UPN format) that you had authorized earlier. In the example below, I am logging into one of my VCSA using user *protected email* and as you can see, I am placed into the appliance shell by default.


At this point I can access all the appliancesh commands just like I normally would if I had logged as a root or *protected email*.

If we wish to change to bash shell, we simply just type "shell" which will enable shell access, assuming you had performed Step 2.


One thing that I noticed is that the default home directory for the AD user is /var/lib/nobody and apparently that does not exists by default, so users end up in / directory by default after enabling shell access. I am not sure if this is also related, but the username shows up as nobody as you can see from the prompt. This is something I will share with Engineering to see if we can improve upon as I am sure most of you would rather see the user that is actually logged in.

The good news from an auditing and logging standpoint is that for operations that are logged, it does properly show the username even though the prompt is showing up as nobody.

[Read more...]