VMWonAWS

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 Leave a Comment

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.

vMotion across different VDS version between onPrem and VMC

09/19/2018 by William Lam 7 Comments

For those of you who have attempted a vMotion (whether that is within a vCenter Server or between different vCenter Servers (including across SSO Domains), if the VM is running on a Distributed Virtual Switch (VDS) and the version of the VDS is not the same between the source and destination (VDS 6.5 to VDS 6.7), the operation will fail with the following error message (UI and API):

Currently connected network interface 'Network adapter 1' cannot use network 'DVPG-VM-Network (VDS-67)', because the destination distributed switch has a different version or vendor than the source distributed switch.

This behavior is no different on VMware Cloud on AWS (VMC) or at least, I thought it was, until I recently learned about a really neat feature that was introduced in the VMC 1.4p2 release, here is a snippet from the release notes:

Cross VDS version vMotion Compatibility
With this advanced configuration option enabled, bi-directional vMotion between on-premises and VMware Cloud on AWS can be achieved across different virtual distributed switch (VDS) versions (greater than or equal to version 6.0). This must be enabled on the on-premises vCenter.

It turns out there is actually a way to allow vMotions across different VDS versions, this is important for VMC because the software stack will always be using a newer version than what we ship to our onPrem customers. However, due to this limitation, we could not benefit from the latest VDS version but had to default it to VDS 6.0 to ensure that customers could migrate their workloads. The advanced setting mentioned in the release notes allows us to disable the strict compatibility check which is performed on the destination vCenter Server when a vMotion is initiated, this setting is now enabled by default on the VMC vCenter Server which is why you can perform migration across different VDS without having to do anything special on your onPrem vCenter Server.

UPDATE (10/16/18) - With the release of vSphere 6.7 Update 1, customers can now also vMotion VMs from on-prem running on a VDS to VMC with NSX-T N-VDS.