virtuallyGhetto

PowerCLI

Retrieving detailed per-VM space utilization on VSAN

by 2 Comments

I was recently helping out my friend Paudie O'Riordan with a request from a customer who was looking for a way to collect detailed space utilization for their VMs (VM Home, VMDK & swap) running on VSAN. Today, this level of granularity is not available in the vSphere UI and the customer was interested in both the used and reserved capacity on a per-VM basis. Luckily, this information can be retrieved using the VSAN Management API.

To do so, we just need to use the VsanQueryObjectIdentities() API method, which I have used in the past to retrieve things like "thick" provisioned VM and translating VSAN Object IDs to their friendly VM display name. To retrieve space utilization information, we just need to set the includeSpaceSummary property to be true. While developing the PowerCLI sample script, I found that this specific property is currently not supported when querying vCenter Server and to retrieve this information, you must go directly to each ESXi host within the VSAN Cluster. I have already filed a feature request and it looks like this will be fixed in a future vSphere release.

[Read more...] about Retrieving detailed per-VM space utilization on VSAN

Quick Tip – How do I tell if NSX-V or NSX-T is installed?

by 1 Comment

This question came up last week asking for a programmatic method to identify whether NSX-V or NSX-T is deployed in your environment. With NSX-V, vCenter Server is a requirement but for NSX-T, vCenter Server is not a requirement, especially for multi-hypervisor support. In this post, I will assume for NSX-T deployments, you have configured a vCenter Compute Manager.

Both NSX-V and NSX-T uses the ExtensionManager API to register themselves with vCenter Server and we can leverage this interface to easily tell if either solutions are installed. NSX-V uses the com.vmware.vShieldManager string to identify itself and NSX-T uses the com.vmware.nsx.management.nsxt string to identify itself.

Here is a quick PowerCLI snippet that demonstrates the use of the vSphere API to check whether NSX-V or NSX-T is installed and provides the version shown in the registration:

Here is a screenshot from my environment which has both NSX-V (6.4) and NSX-T (2.1) installed:


Note: Due to some current testing, I have not upgraded my NSX-T deployment to the latest 2.2 release, so I do not know if the version gets bumped to match the actual released version

vGhetto Automated Pivotal Container Service (PKS) Lab Deployment 

by 3 Comments

While working on my Getting started with VMware Pivotal Container Service (PKS) blog series awhile back, one of the things I was also working on was some automation to help build out the required infrastructure NSX-T (Manager, Controller & Edge), Nested ESXi hosts configured with VSAN for the Compute vSphere Cluster and Pivotal Ops Manager. This was not only useful for my own learning purposes, but that I could easily rebuild my lab if I had messed something up and allowed me to focus more on the PKS solution rather than standing up the infrastructure itself.

To be honest, I had about 95% of the script done but I was not able to figure out one of the NSX-T APIs and I got busy and had left the script on the back burner. This past weekend while cleaning out some of my PKS research documents, I came across the script and funny enough, in about 30minutes I was able to solve the problem which I was stuck for weeks prior. I just finished putting the final touches on the script along with adding some documentation. Simliar to my other vGhetto Lab Automation scripts, I have created a Github repo vGhetto Automated PKS Lab Deployment

UPDATE (06/19/18) - I have just updated the script to also include the deployment and configuration of the PKS components (Ops Manager, BOSH Director, Harbor & Stemcell). The script by default will now configure everything end-2-end and you will have a fully functional PKS environment that you can start playing around with. For complete details, please see the Github repo which has the updated requirements and documentation. Below is a screenshot of the PKS deployment and configuration which requires the use of the Ops Manager CLI (OM).


The script will deploy the following components which will be placed inside of a vApp as shown in the screenshot below:

  • NSX-T Manager
  • NSX-T Controller x 3 (though you technically only need one for lab/poc purposes)
  • NSX-T Edge
  • Nested ESXi VMs x 3 (VSAN will be configured)
  • Ops Manager


The script follows my PKS blog series and automates Part 3 (NSX-T) and the start of Part 4 (Ops Manager deploy), please refer to these individual blog posts for more information. The goal of the script is to enable folks to jump right into the PKS configuration workflows and not have to worry about setting up the actual infrastructure that is needed for PKS. Once the script has finished, you can jump right into Ops Manager and start your PKS journey.

Here is a sample execution of the script which took ~29 minutes to complete.


The full requirements for using the script be found on the Github repo and below are the software versions that I had used to deploy and configure PKS:

How do you “log a reason” using PowerCLI when rebooting or shutting down ESXi host?

by 1 Comment

I am sure many of you have seen this UI prompt asking you to specify a reason before issuing a reboot or shutdown of an ESXi host and I assume most of you spend a few seconds to type in a useful message and not just random characters, right? 😉


Have you ever tried performing the same reboot or shutdown operation using the vSphere API or PowerCLI (which leverages the API)? Have noticed, there is not a way to specify a message like you can in the UI?

Here is a table of the PowerCLI cmdlets and the respective vSphere API that is used to perform these two operations:

Operation Cmdlet vSphere API
Reboot  Restart-VMHost  RebootHost_Task
Shutdown  Stop-VMHost  ShutdownHost_Task

When looking at either the PowerCLI and/or vSphere API documentation, we can confirm that there are no fields to specify a message which can lead to an assumption that this is simply not possible or that the functionality might be provided by a private API. Fortunately, this is not the case and the functionality is in fact in the public vSphere API and has been for quite some time.

When you specify a message prior to rebooting or shutting down, this message is actually persisted and implemented as an Event within vCenter Server as shown in the screenshot below.

Instead of being able to specify a message that is only applicable to an ESXi host, I believe the original vSphere API designers thought that this functionality could also be useful and applied more broadly across any number of the vSphere Inventory objects, not just ESXi hosts. As such, this functionality which the vSphere UI uses is provided by the LogUserEvent() method which is part of the EventManager API. Customers or solutions can leverage this mechanism to log custom user defined events which is then persisted with the lifecycle fo the vSphere Inventory Object or as far back as your retention period for vCenter Server Events.

Going back to our original question, if you want to specify a message prior to rebooting or shutting down an ESXi host, the following snippet below demonstrates the use of the vSphere API via PowerCLI:

Leveraging Instant Clone in vSphere 6.7 for extremely fast Nested ESXi provisioning

by 8 Comments

The idea of "Instant Cloning" a Nested ESXi VM (running ESXi in a VM) is not a new concept. In fact, I had shared a solution back in 2015 using the private VMFork APIs. However, what has changed is the ease of consumption, primarily due to the re-architecture of Instant Clone in vSphere 6.7 (more details here and here) which resulted in a public and simplified API. Some of you might ask, why not simply clone a Nested ESXi VM or create a Link Clone? What benefit would I get by using Instant Clone?

The answer is not only speed, but the fact that the instantiated VM is fully operational and ready to start executing where as a traditional full clone or linked clone requires a full OS boot up that can take up to several minutes to deploy and configure. This may not sound like much for a small number of Nested ESXi VMs, but as you increase the number of instances, Instant Clone really shines while still maintaining speed and the instant availability of the VM. As you can imagine, this definitely opens up for some interesting use cases whether it be for personal home lab or educational purposes like VMware HOL. In addition, we also have customers who deploy Nested ESXi not only at high scale but also with a high churn rate for development purposes, think CI/CD type of a workload who can also benefit from Instant Clone.

So how fast are we talking about? Lets say you wanted to test out the latest version of VSAN in vSphere 6.7, you would normally deploy 3 Nested ESXi VMs, power them up and wait for them to be ready on the network. With Instant Clone, you can deploy three fully functional Nested ESXi VMs in just 30seconds! As the VMs are instantly available for consumption, you can start the VSAN enablement workflow immediately and even parts of that can be baked into the Instant Clone workflow. With the ease of provisioning Nested ESXi VMs, you can simply maintain a catalog of ESXi templates which are in "frozen" states and then leverage Instant Clone to deploy just-in-time Nested ESXi environments and discard them once you are done. Pretty slick if you ask me! and something I plan on using going forward.

Disclaimer: Nested ESXi is still not officially supported by VMware. Please use at your own risk.

[Read more...] about Leveraging Instant Clone in vSphere 6.7 for extremely fast Nested ESXi provisioning

New Instant Clone Architecture in vSphere 6.7 – Part 2

by 3 Comments

In the previous article, I provided an overview of the new "Parentless" Instant Clone feature which was introduced in vSphere 6.7 and some of the architectural differences between prior versions of Instant Clone. In this post, I will show you how to use the new Instant Clone feature, which is currently only available with the vSphere API.

There are two important parts when using Instant Clone:

  1. A user defined script which runs within the GuestOS and is responsible for customizing the network identity of the Instant Clone. This script is not just limited to network configurations but can also be used to customize other OS and/or application settings.
  2. The deployment script which runs outside of the GuestOS and instantiates new Instant Clones using the vSphere API. This script is responsible for passing in data (network configuration, OS and/or application settings) to the GuestOS which can then be accessed directly by the user defined script running within each Instant Clone for actual customization.

To demonstrate the use of the Instant Clone API, I will be using PowerCLI and have also created an Instant Clone PowerCLI module called InstantClone.psm1. However, the API is not limited to just PowerCLI and can be consumed using any of the new vSphere 6.7 SDKs. For our example, we will be exercising the creating Instant Clones from a "Frozen" Source VM workflow since that is the most efficient method, especially as you scale to larger number of Instant Clones. For those that wish to experiment with the other workflow of creating Instant Clones from a "Running" Source VM, feel free to take a look at the previous post for the required steps.

For my setup, I will be using an Ubuntu Server 16.04 system as my Source VM and I will create 30 Instant Clones from this system. Each Instant Clone will immediately be available for use and will be fully customized and reachable from a network perspective (e.g. unique IP and MAC Address). Here is a screenshot of one of my deployments to give you an idea of how blazing fast Instant Clone is 🙂

Here is a short video that I just recorded that demos the Instant Clone APIs using PowerCLI (this demo is using an Ubuntu VM configured with 2GB memory where as the original screenshot was 1GB)

Demo of Instant Clone in vSphere 6.7 from lamw on Vimeo. [Read more...] about New Instant Clone Architecture in vSphere 6.7 – Part 2