VMWonAWS

ESXTOP and VMware Cloud on AWS

03/26/2019 by William Lam 6 Comments

ESXTOP is one of the most versatile and popular tool in the VI Administrators tool belt when it comes to real time performance analysis and data collection in a vSphere environment. In fact, ESXTOP also came up in the most recent episode of the VirtuallySpeaking Podcast covering the Top 10 Tools for VI Administrators, which Duncan Epping and I had the pleasure to be part of.

To use ESXTOP, you are required to SSH to an ESXi host as it is only available in the ESXi Shell. Traditionally, this has not been a huge issue for on-premises environment, especially as you can enable access when you needed to run ESXTOP. However, when operating on VMware Cloud on AWS (VMC), customers no longer have to worry about managing the underlying infrastructure and can now focus on being a consumer of the VMware SDDC. One side affect of this operational change is that customers do not have direct access to ESXi and would not be able to use ESXTOP.

New VMC API to rename SDDC

01/12/2019 by William Lam Leave a Comment

A commonly requested feature in VMware Cloud on AWS (VMC) is the ability to rename an SDDC. Currently, it is not possible to rename an SDDC after it has been deployed. On Friday, an update was made to the VMC Service to introduce a new VMC API (Tech Preview) that will allow customers to rename their SDDC. The API is just the first step and our UI folks are already working on adding this natively to the VMC UI which I actually got a sneak peak of just a few days ago.

UPDATE (02/11/19) - The ability to rename an SDDC is now also available within the VMC Console UI, so you can use either UI or API to perform this operation.

The new SDDC rename API is very straight forward to use, you simply perform a PATCH operation the specific SDDC /orgs/{orgID}/sddcs/{sddcID} which includes a payload containing the updated name. Below are three ways in which you can easily rename your SDDC, including a UI method for those that want to quickly rename an SDDC and not have to write a single line of code.

Quick Tip – How to clear all Hybrid Cloud Extension (HCX) Migrations in the vSphere UI

10/11/2018 by William Lam Leave a Comment

During the development of my Cloud Motion with vSphere Replication automation script for Hybrid Cloud Extension (HCX), I extensively used the HCX vSphere UI for testing and debugging purposes.

Under the Migration view, you can see all active and completed migrations, including any failed migration attempts. In my particular environment, there had been a few hundred migrations and with my additional testing, that added quite a few more. Although you can filter by name or sort by the type of operation, it was still not very convenient for me while developing the script. I wanted a quick way to view the details after calling the HCX APIs and by the time I jumped to the UI, I would have missed a few of those updates.

In speaking with one of the HCX Engineers, I found out that you could simply drop all migration history from the internal database (this would remove all the history for past migrations including failures). In general, I do not see this being something customers would have a need for in Production, as you would want to keep all the history for auditing or debugging purposes. This is probably more for demo or testing purposes and below are the instructions on how to clear all migrations from your HCX Manager.

Enhancements to Hybrid Linked Mode (HLM) in VMC using the new vCenter Cloud Gateway

10/04/2018 by William Lam Leave a Comment

It has been almost a year since VMware introduced the Hybrid Linked Mode (HLM) capability, which provides customers with a consistent operating experience for managing and consuming resources from both their on-premises and VMware Cloud on AWS (VMC) environments. Feedback from customers on HLM has been fantastic, especially when new or prospective VMC customers learn about HLM for the very first time. Customers were pleasantly surprised at how seamless the experience was when consuming VMC resources, using a familiar interface, the vSphere UI.

Here is a quick recap of what HLM provides today:

HLM allows customers to link a single VMC instance to a single on-prem SSO Domain which can contain one or more vCenter Servers (Enhanced Linked Mode) while maintaining separate administrative domains (e.g. on-prem user is Administrator while VMC user is CloudAdmin only)
SSO Domains will be different between on-prem and VMC, however it is a 1:1 relationship
A trust is established where the on-prem vCenter Server trusts the incoming connections from VMC as they share the same Active Directory identity source. Data is sync'ed uni-directionally from on-prem to VMC
Can be configured at any point in the on-prem vCenter Server lifecycle, no restrictions to initial install and can easily be un-linked unlike ELM
Both Embedded & External vCenter Server deployments are supported
HLM supports different versions of vCenter Server between on-prem (6.5d+) and VMC, especially as VMC will almost always run a newer version of vSphere
Users MUST login to VMC vCenter Server for single-pane of glass management (H5 Client supported only), logging into on-prem vCenter Server will NOT show VMC vCenter Server
Roles are NOT replicated due to the restrictive access model in VMC

Nested ESXi on VMware Cloud on AWS (VMC)

09/28/2018 by William Lam 2 Comments

I have had a few folks ask about Nested ESXi support on VMware Cloud on AWS (VMC), so lets get that out of the way first. Nested ESXi is NOT supported by VMware on any of our platforms, whether that is an on-premises or a cloud environment like VMC or any 3rd party vendors that maybe using VMware software. For those wanting an "official" statement on Nested ESXi support, you can refer to KB 2009916.

Now, we all know Nested ESXi works and it runs extremely well on vSphere. In fact, vSphere is the best platform for running any Hypervisor in a VM. This is also true for VMC, you can run a Nested ESXi VM in an SDDC, however there are some caveats compared to what you would experience in an on-prem environment. Below are some of the caveats to be aware of if you are considering running Nested ESXi on VMC.

Create vCenter Alarms for monitoring HCX migration events

09/20/2018 by William Lam 1 Comment

With the Hybrid Cloud Extension (HCX) solution, customers can migrate workloads immediately or have them scheduled at a later date and time of their choosing. Most customers will most likely not migrate all their workloads at once, but instead migrate them in different phases or waves based on their own internal schedules. The HCX "Migration" tab in the vSphere Client is a great place to get an overview of all the active, failed, planned and completed migrations and you can get additional details for each migration such status, percentage, amount of data transferred, etc.

Having said that, you probably also do not want to just sit there and constantly watch for progress, especially if something fails. The good news is that HCX already includes some default vCenter Alarms that are generated when a migration fails. There is one for vMotion/Cloud Motion, Cold Migration as well as Bulk Migration and currently these alarms only trigger a UI indication that something is wrong using the red critical icon on the VM in question.

Since these are vCenter Alarms, you also have the option of adding additional actions such as sending an email alert to a particular user or group, an SNMP trap which can then be monitored by your operations team or even run a command within the vCenter Server. Simply updating the default alarm which is defined at the vCenter Server level, you can proactively get notified when an HCX migration fails without having to constantly watch the UI. You may have also noticed the alarm definition is using a numeric ID which is highlighted in the screenshot above. This maybe useful if you wish to leave the default alarms alone and create a brand new alarm, you just need to use those IDs.

Another useful scenario to consider is getting notifications for a successful migration which can then help with transitioning users to the new VM running on VMC or even trigger automated VM and application verification before end users are even notified. Along these similar lines, you can imagine another scenario to consider is with using Bulk Migration and/or Cloud Motion with vSphere Replication. Both methods initially start off by replicating the VM's data from the source vCenter Server to the destination vCenter Server and then either a Cold Migration or vMotion is performed based on the configured scheduled.