How to limit the number physical CPU sockets in ESXi?

Last week I received a very strange customer inquiry in which they would like to limit the number of physical CPU sockets seen by ESXi. As you can imagine, my interest was piqued as this is usually not the type of request you hear from customers looking to actively reduce the overall computing power of their underlying hardware, especially if they have paid for it. After digging into the details a bit more, it turns out this is related to licensing.

The customer is running an application on a VM which is licensed by the total number of underlying physical CPU sockets of the server, regardless if they are actively being used by the application or not. The vendor shall be left nameless but I am sure some of you can make some educated guesses :) The customer was in the process of performing a hardware refresh where they would be moving from a 4 socket CPU to an 8 socket CPU and they would be negatively impacted by this change from a licensing standpoint. I can understand their concerns, they have now just doubled their application licensing cost without actually benefiting from the actual hardware update.

Luckily, because the customer is running vSphere ESXi, there is a neat little capability that may not be that well know which allows you to actually limit the number of physical CPUs seen by ESXi. This capability is exposed as an ESXi Advanced Setting called VMkernel.Boot.maxPCPUS and by default, this is set to unlimited as you would expect. You can change this setting using a variety of methods including the vSphere Web Client, vSphere C# Client, ESXi Embedded Host Client, vSphere API which includes ESXCLI & PowerCLI. Here is a great example in which you can actually save money by running vSphere in addition to all the other benefits 😀

Using the customer example, if I have a server that has 8 physical CPUs and I want to change that to 4 physical CPUs, then I just need to adjust the value to 4. Once you have made the change, you will need to reboot the ESXi host for the changes to go into effect and when you login to the ESXi host, you will see that the number of physical CPUs have now been reduced and no longer visible to ESXi. Another option which I have seen some postings online about which is the ability to turn off specific CPUs for certain hardware platforms using the system BIOs, having said that, I have not actually seen any real confirmation that this is in fact possible.

Note: There is no way to limit the specific number of cores on a physical CPU socket other than disabling Hyperthreading from system BIOs.

Below are screenshots using the vSphere C# & ESXi Embedded Host.

limit-maximum-physical-cpu-in-esxi-0

limit-maximum-physical-cpu-in-esxi-1
If you prefer to to use the CLI either locally or remotely, you can run the following ESXCLI commands:

List the current configurations

esxcli system settings kernel list -o maxPCPUS

Set a new configuration

esxcli system settings kernel list -s maxPCPUS -v 4

limit-maximum-physical-cpu-in-esxi-2

Automating vRealize Automation 7 Simple Minimal: Part 2 - vRA IaaS Agent Deployment

In Part 2 of this blog series, we will be looking at automating the installation of the vRA IaaS Management Agent which needs run on a Microsoft Windows system. The IaaS Management Agent installer is provided through the vRA Appliance which you can downloaded by opening a browser to the following URL:

https://[VRA_APPLIANCE_HOSTNAME]:5480/installer/download/vCAC-IaaSManagementAgent-Setup.msi

When installing the agent, you will need to provide information about the vRA Appliance that you wish to register the IaaS Management Agent with. The following Powershell script called installvRAIaaSAgent.ps1 will automatically download the vRA Iaas Management Agent from the vRA Appliance and then perform a silent installation. There are 5 mandatory variables that you will need to edit before running the script and the table below describes each of their functions:

Variable Description
VRA_APPLIANCE_HOSTNAME  Hostname or IP of vRA Appliance
VRA_APPLIANCE_USERNAME  Username of vRA Appliance (default: root)
VRA_APPLIANCE_PASSWORD  Password of vRA Appliance
VRA_APPLIANCE_AGENT_DOWNLOAD_PATH  Path to store vRA Agent (optional)
VRA_APPLIANCE_AGENT_INSTALL_LOG  Path to store vRA Agent install logs (optional)
VRA_IAAS_SERVICE_USERNAME OS username to the vRA IaaS Windows System
VRA_IAAS_SERVICE_PASSWORD OS password to the vRA IaaS Windows System

Here is an example of running the script on my vRA IaaS Windows system:

automating-vrealize-automation-7-iaas-agent
In the final part of this series we will take a look at automating the configuration of both the vRA Appliance which includes Horizon SSO and the vRA IaaS Windows system which includes the various IaaS components.

Automating vRealize Automation 7 Minimal Install: Part 1 - vRA Appliance Deployment

Over the last couple of weeks, I have received numerous requests about automating the deployment of the recently released vRealize Automation 7 (vRA) similar to what I did for vCloud Automation Center 6.0 when it was released. To be honest, I have not spent much time with vRealize Automation as you can see from my last post, it was dated back in 2013. I know there have been some significant improvements in the latest vRA release and perhaps it now officially supports silent or scripted installs like the vCenter Server Appliance (VCSA).

I was a bit bummed to hear that this capability still had not made it into the product which would make streamlining proof of concept and Production deployments a breeze. I mean, why would you want to manually install it if you could automate, right? :) I figure I reach out to one of my vRA Engineering buddies Kim Delgado to see if anything had already been done in this area. She was nice enough to share a couple of resources which cover certain parts of the deployment but nothing that was tying everything together.

I figure I would see what I could re-purpose and try to put together a few simple scripts that would allow anyone to easily stand up a minimal vRA 7 deployment for testing and POC purposes. I normally like prove everything out before publishing but in this case, I figure I would just go with the flow. So far, I have broken down the automation into the following three sections listed below. I have successfully completed Part 1 and Part 2 and I have not attempted Part 3, so I do not know it it will be possible or what issues I might run into.

Note: You can deploy vRA 7 in either a minimal setup which has just the vRA appliance and vRA IaaS system running or in a fully distributed model which they are calling Enterprise. In the series, I will only be covering the minimal deployment. For those interested in a distributed deployment, hopefully you will be able to build upon the scripts that I have created and should be a fun learning exercise for those looking to do more automation.

In part 1 of this series, I will be covering the deployment of the vRA 7 Appliance and have created the following PowerCLI deployment.ps1 script. There are several properties you will need to fill out such as the networking configuration, OS credentials, etc. before you can run the script. Once the script completes, you can verify that the deployment was successful by opening a browser to VAMI interface of the vRA Appliance using the following URL: https://[VRA-HOSTNAME]:5480

automating-vrealize-automation-7-appliance
Stay tuned for Part 2 next week where I will be covering how to automate the installation of the vRA IaaS Management Agent.

New vSphere 6.0 API for configuring SMP-FT

Symmetric Multi-Processing Fault Tolerance (SMP-FT) is a new feature that was introduced in vSphere 6.0 which allows you to enable FT against a Virtual Machine with up to 4 vCPU. In addition to this new functionality, a new vSphere 6.0 API was also introduced to allow customers to easily manage this from an Automation standpoint. Previously, the CreateSecondaryVM_Task() vSphere API was used to enable Uni-Processing Fault Tolerance (UP-FT). With SMP-FT, there is a now a new vSphere API method called CreateSecondaryVMEx_Task() which supports a few additional parameters which is now required for enabling FT (UP-FT & SMP-FT) compared to the old "Legacy FT" mode.

smp-ft-vsphere-api

Disclaimer: The example script is meant to be used for educational purposes. Please ensure proper testing is done if you decide to use it for Production environments.

I have created a small PowerCLI script called Set-FT.ps1 which exercises this new vSphere 6.0 API and below are examples on how to turn on or off SMP-FT for a VM:
Turning On SMP-FT

Set-FT -vmname "SMP-VM" -Operation on -Datastore "vsanDatastore" -Vmhost "vesxi60-5.primp-industries.com"

Turning off SMP-FT

Set-FT -vmname "SMP-VM" -Operation off -Datastore "vsanDatastore" -Vmhost "vesxi60-5.primp-industries.com"

vSphere SDK for JavaScript Fling released

The VMware Fling team has just released another cool new Fling, the vSphere SDK for JavaScript. This Fling is especially interesting as it provides the underlying SDK framework used by the popular ESXi Embedded Host Client Fling which was released back in August of last year. I came to learn about this project during last years internal R&D Innovation Offsite (RADIO) conference which is held annually and can be thought of as the VMworld conference for VMware employees.

One of the biggest highlight of the conference for me personally is checking out the expo floor where you get to see what other VMware Engineering teams have been working on whether it is the next big feature, product or new ideas that they might be thinking about. It was during my walk through that I met Rostislav Hristov, one of the Engineers who worked on the vSphere SDK for JavaScript. I was really impressed at what Rostislav built and luckily he was already in touch with the Embedded Host Client Engineers to see how they could leverage his JavaScript SDK as the initial prototype had made calls directly using the vSphere MOB which was not very friendly to develop against.

There has been a number of improvements to the vSphere SDK for JavaScript since I last saw it and although the name contains "vSphere", it definitely supports more than just the vSphere API endpoint. In fact, with this single SDK you can interact with vCenter Server Single Sign-On (SSO) API, vCloud Suite API which covers capabilities like Tagging and Content Library as well as the Site Recovery Manager (SRM) APIs! For customers and partners that are looking to develop their own web portals or interfaces that can integrate with these APIs, this will be a handy tool to have.

To get started, the vSphere SDK for JavaScript contains a README file that contains additional instructions on setting up the SDK as well as a couple of samples that demonstrates each of the supported API endpoints:

  • vimService.js - Sample using the vSphere API
  • stsService.js - Sample using the SSO API
  • cisServices.js - Sample using the vCloud Suite API
  • srmService.js - Sample using the SRM API

Here is the command to run the vimService.js sample which will also require you to set the environmental variable NODE_TLS_REJECT_UNAUTHORIZED=0 if you are using the default VMware self-signed SSL Certificate.

NODE_TLS_REJECT_UNAUTHORIZED=0 babel-node samples/vimService.js

vsphere-sdk-for-javascript-0
Once the sample has started up, you will be prompted with a URL to open in your browser. In the vimService.js example, you will be able to login to either a vCenter Server or ESXi host as seen in the screenshot below.

vsphere-sdk-for-javascript-1
Once logged in, you should see a simple listing of the different inventory objects in your vSphere enviornment.

vsphere-sdk-for-javascript-2
In the stsService.js sample, once logged in by specifying the address to your PSC/SSO instance, you should see that a SAML token was issued.

vsphere-sdk-for-javascript-3
The cisService.js sample exercises several operations using a mixture of both the vSphere API as well as the new vCloud Suite API. It does require connecting to a vCenter Server 6.0 environment as it will be performing operations using the new vSphere Content Library feature as well as some VM operations. Do not worry, once the operations have been completed, the script will automatically clean itself up. This is a great sample if you want to see how you could make use of the different APIs all through this single SDK.

vsphere-sdk-for-javascript-4-new
I did not have an SRM environment up and running to test the srmService.js sample, but you can see from the code that it will list all of the recovery plans and their current state. For more details on how the individual APIs work, you can refer to the documentation included in the vSphere SDK for JavaScript or the official API documentation for the individual products. If you have any feedback or comments about this Fling, please leave a comment on the Fling site here as I am sure the Engineers would love to hear what you think!