vSphere – Page 71

How to limit the number "Logical" CPUs in ESXi?

02.09.2016 by William Lam // 13 Comments

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.

Unfortunately, after a bit more research, I found that it is not possible to reduce or limit the number of physical CPU sockets from ESXi. The only capability that we do have today around this topic is to limit the number of Logical CPUs that ESXi can see. 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. What this setting does is takes the total number of logical CPUs that you wish to expose to ESXi and then evenly distributes that across your physical CPU Sockets as best as it can.

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. One alternative which I have seen some postings online about which is the ability to turn off specific CPU sockets for certain hardware platforms by using the system BIOs, having said that, I have not actually seen any real confirmation that this is in fact possible.

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

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

vSphere SDK for JavaScript Fling released

02.03.2016 by William Lam // 2 Comments

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

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.

Once logged in, you should see a simple listing of the different inventory objects in your vSphere enviornment.

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.

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.

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!

Hidden OVF 2.0 capablity found in the vSphere Content Library

01.12.2016 by William Lam // 5 Comments

There are a number of new and useful capabilities that have been introduced in the OVF 2.0 specification. One such capability which I thought was really interesting and that could easily benefit VMware-based solutions is the ScaleOutSection feature. This feature allows you specify the number of instances of a given Virtual Appliance to instantiate at deployment time by making use of pre-defined OVF Deployment Options which can also be overriden by a user.

Lets use an example to see how this actually works. Say you have a single Virtual Appliance (VA) and the application within the appliance can scale to N, where N is any number greater or equal to 1. If you wanted to deploy 3 instances of this VA, you would have to deploy it 3 separate times by either by running through an OVF upload or deploying it from a template. In either case, you are performing N-instantiations. Would it not be cool if you could still start with a single VA image and specify at deployment time the number of instances you want to deploy and only need to upload the VA just once? Well, that is exactly what the OVF ScaleOutSection feature provides.

Below is a diagram to help illustrate this feature further. We start out with our single VA, which contains several pre-defined Deployment Options which can contain any text you wish for the logical grouping. In this example, I am using the terms "Single", "Minimal" and "Typical" to map to number of VA's to deploy which are 1, 3, and 4 respectively. If we choose the "Minimal" Deployment option, we would then get 3 instantiated VA's. If we decide that the defaults are not sufficient, we could also override the default by specifying a different number which the VA supports.

A really cool use case that I had thought about when I first came across the ScaleOutSection feature was to make use of it with my Nested ESXi Virtual Appliance. This capability would make it even easier to standup a vSphere or VSAN Cluster of any size for development or testing purposes. Today, vSphere and many of the other VMware products only support OVF 1.x specification and as far as I know, OVF 2.0 was not something that was being looked at.

Right before holiday break, I was chatting with one of the Engineers in the Content Library team and one of the topics that I had discussed in passing was OVF 2.0 support. It turns out that, although vSphere itself does not support OVF 2.0, the vSphere Content Library feature actually contains a very basic implementation of OVF 2.0 and though not complete, it does have some support for the ScaleOutSection feature.

This of course got me thinking and with the help of the Engineer, I was able to build a prototype version of my Nested ESXi Virtual Appliance supporting the ScaleOutSection feature. Below is a quick video that demonstrates how this feature would work using a current release of vSphere 6.0. Pretty cool if you ask me!? 🙂

Demo of Prototype Nested ESXi Virtual Appliance using OVF 2.0 ScaleOut from lamw on Vimeo.

Now, before you get too excited. There were a couple of caveats that I found while going through the deployment workflow. During the deployment, the VMDKs were not properly being processed and when you power on the VMs, it was as if they were empty disks. This was a known issue and I have been told this has already been resolved in a future update. The other bigger issue is how OVF properties are handled with multiple instances of the VA. Since this is not a supported workflow, the OVF wizard is only brought up once regardless of the number of instances being deployed. This means that all VAs will inherit the same OVF values since are you are only prompted once. The workaround was to deploy the VAs, then go into each individual VA and update their OVF properties before powering on the VMs. Since OVF 2.0 and the ScaleOutSection feature is not an officially supported feature, the user experience is not as ideal as one would expect.

I personally think there are some pretty interesting use cases that could be enabled by OVF 2.0 and ScaleOutSection feature. A few VMware specific solutions that I can think of off the top of my head that could potentially leverage this capability are vRealize Log Insight, vRealize Operations Manager and vRealize Automation Center to just name a few. I am sure there are others including 3rd party and custom Virtual Appliances that have been developed and I am curious to hear if this is something that might be of interest to you? If you have any feedback, feel free to leave a comment and I can share this with the Content Library PM.