virtuallyGhetto

William Lam

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.

Use cases for Anti-Affinity VM-Host Rules

by 5 Comments

I was in a meeting last week with Engineering and a question had come up on whether customers were actively using the Anti-Affinity (AA) VM-Host Rules capability and if so, what are some of the use cases?  We know that Anti-Affinity VM-VM Rules are used quite regularly by customers and the use cases are pretty well understood, but what is not clear was the usage and frequency of AA VM-Host rules. I figured I could help Engineering by asking some of my Twitter folllowers, the following question:

In an attempt to avoid any confusion, I also included a screenshot of the AA VM-Host Rules in the vSphere UI which you can see above. However, it looks like my attempt had failed and I actually received a number of replies that described AA VM-VM Host Rules (separate certain groups of VMs from each other, regardless of host groups), rather than AA VM-Host Rules (do not run certain groups of VMs on specific host groups). Perhaps the question could have been better phrased or it was just a simple misinterpretation, but overall it was a very useful exercise and it was great learn about all the different use cases for BOTH AA VM-VM and AA VM-Host Rules, so thank you to everyone who shared their feedback.

[Read more...] about Use cases for Anti-Affinity VM-Host Rules

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

 

New Adventure

by 5 Comments

It is hard to believe this Fall will be my 7th year at VMware! Looking back, it has absolutely been an amazing ride.

For the past six years, I have been very fortunate to have been part of an amazing team of solutions architects working within R&D as part of the Integrated Systems Business Unit (ISBU) at VMware. In the early days, we were known as the Integration Engineering team, most well known for designing, operating and running the original VMware Hands on Lab at VMworld which used to also include on-premises hardware! This team also served as Customer[0] internally for a number of VMware products. In addition, this team also ran the customer on-site Alphas and Betas for vSphere. I still remember building the very first vPod for what eventually became vSphere 6.0 🙂

Over the years, the team had built up a wealth of knowledge in how to build, run and operate the VMware SDDC at scale. A large part of the team had came from either the field or from a customer with past alumnis including Duncan Epping, Cormac Hogan & Paudie O'Riordan to name a few. We wanted to bring these learnings and best practices to our customers and the VMware Validated Design (VVD) was born. What customers most appreciate about the VVDs is not just the Day 0 guidance, but also the prescriptive Day 2 operational guidance (patching/upgrading, maintenance window scheduling, monitoring, disaster recovery, etc) which is not something VMware had historically provided. Customers can then consume the VVD in several ways: build it yourself (DIY), PSO engagement including Automation or through VMware Cloud Foundation (VCF) which codifies the VVD into an integrated hardware/software offering. I am very proud of what the team has built over the years, it was not an easy road and not compromising on our design principles has paid dividends as we continue see the VVD adoption accelerating in our customers environments as the fastest way to deliver a VMware SDDC.

For the last couple of years, I had also been driving an internal project within ISBU called the Enterprise Readiness Initiative (ERi). This effort is focused on ensuring that we have a consistent set of capabilities across Lifecycle, Certificate & Configuration Management for the VMware SDDC. These capabilities must also be exposed programmatically for our customers and partners to consume. One example is the recent Install/Upgrade vCenter REST APIs that was made available as part of the vSphere 6.7 release. There is still plenty more work to be done including other ERi workstreams, but the team has made some great progress and hopefully you will be seeing more of the results in the near future.

As you can see, there is no shortage of oppournitites at VMware and being able to work with so many talented and passionate colleague to help solve our customer challenges is what I wake up every day for. I wanted to take a moment and thank one of the best managers I have had the pleasure of reporting to, Phil Weiss. Not only has he been very supportive of my career development, but has also been a mentor to me over the years and I have learned a tremendous amount from him and about myself. Phil is also occasionally involved when I get called into the lawyers office 😉 I also wanted to extend my thanks to both John Gilmartin (ISBU GM) and Jayanta Dey (ISBU VP of Engineering) who were both extremely supportive of my decision to move on.

[Read more...] about New Adventure

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