virtuallyGhetto

Automation

Retrieving detailed per-VM space utilization on VSAN

by Leave a Comment

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

Using ESXi Kickstart %firstboot with Secure Boot

by 3 Comments

If you install ESXi via a Kickstart script and make use of the %firstboot option to execute commands on the first boot of the ESXi host after installation, you should be aware of its incompatibility with the Secure Boot feature. If you install ESXi where Secure Boot is enabled, the Kickstart will install ESXi normally only execute up to the %post section. However, it will not execute the %firstboot scripts and if you look at the /var/log/kickstart.log after the host boots, you should see the following message:

INFO UEFI Secure Boot Enabled, skipping execution of /var/lib/vmware/firstboot/001.firstboot_001

If you have Secure Boot enabled, %firstboot is not supported. The reason for this is Secure Boot mandates only known tardisks which can hold executable scripts, and a kickstart script is an unknown source so it can not run when Secure Boot is enabled. If you wish to continue using %firstboot scripts, the only option is to disable Secure Boot and then re-enable it after the installation. A preferred alternative is to convert your %firstboot logic into an external script which can then be applied using the vSphere API (recommended method) and this way you can still customize your ESXi host after the initial installations. I have already filed an internal documentation bug to add a note regarding Secure Boot and %firstboot, hopefully that will roll out with the net documentation refresh.

OVFTool and VMware Cloud on AWS

by Leave a Comment

Recently, I had noticed a number of questions that have come up regarding the use of OVFTool with the VMware Cloud on AWS (VMC) service. I had a chance to take a look at this last Friday and I can confirm that customers can indeed use this tool to import/export VMs into VMC whether they are from a vSphere/vCloud Director-based environment or simply OVF/OVAs you have on your desktop. Outlined below are the requirements and steps that you must have setup before you can use OVFTool with VMC. In addition, I have also include an OVFTool command snippet which you can use and adapt in your own environment.

Requirements:

  1. You must setup VPN connection between your onPrem environment and the Management Gateway on VMC (direct internet access to ESXi is not supported)
  2. Configure the VMC Firewall to allow access between your onPrem and VMC's ESXi host on port 443 (data transfer occurs at ESXi host level)
  3. Specify the Workload VM Folder as a target
  4. Specify the Compute-ResourcePool Resource Pool as a target
  5. Specify the WorkloadDatastore Datastore as a target

Instructions:

Step 1 - Create a Management VPN connection, please see the official documentation here for more details.

Step 2 - Create a two new Firewall Rules that allow traffic from your onPrem environment to both vCenter Server and ESXi host on port 443. vCenter Server will obviously be used for UI/API access and for ESXi, this is where the data traffic transfer will take place.


Step 3 - Construct your OVFTool command-line arguments and ensure you are using the VM Folder "Workloads", Resource Pool "Compute-ResourcePool" and Datastore "WorkloadDatastore" as your target destination since the CloudAdmin user will have restrictive privileges within VMC.

Here is an example command to upload an OVA from my desktop to the VMC vCenter Server:

Note: OVFTool also supports the ability to specify a VM that is residing in your vSphere environment as a source, so you do not have to export it locally to your desktop and you can directly transfer it (your client desktop acting as a proxy) to VMC.

Here is the output from running the above command:


Once the upload has completed, you should see your new VM appear in your vSphere Inventory

 

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

by Leave a 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:

Feedback on default behavior for VM Storage Policy

by Leave a Comment

Today, the vCenter REST (vSphere Automation) APIs currently does not support the use of VM Storage Policies when relocating (vMotion, Cross Datacenter vMotion & Storage vMotion) or cloning an existing Virtual Machine. Customers have provided feedback that this is something that they would like to see get added to the current REST APIs and while this is being looked at, there were a couple of open questions from Engineering.

The following 2-question survey below is to help us understand what the "default" behavior should be when a Virtual Machine is being relocated or cloned within a vCenter Server and a VM Storage Policy is NOT specified when using the APIs. The reason for this is that our existing APIs for relocate and clone today are very flexible and not everything needs to be specified as part of the relocate or clone API specification. However, due to this flexibility, you may observe different behaviors and we would like to understand what the default behavior should be when some of these paraemters are not specified. In the case where you want to be explicit, you can always specify the VM Storage Policy, but the survey is to understand when it is not specified.

Survey: https://goo.gl/forms/aQjVTly2MmVHeRsp1

Thank you  for taking the time to provide your feedback, this will help us build an easy and robust API when dealing with relocate and clone operations using the vCenter REST APIs.