vExpert 2022 Applications Are Open….But Why Apply?!

The application season is here, and being in my third year, I’ve had some time to reflect on my experience of being a vExpert. But first….

If you are still wondering…..what is the VMware vExpert program?

The vExpert program is an evangelism and advocacy program designed to promote individuals that contribute to communities with their expertise in VMware products and services. The award is given for one year and is given to individuals, not companies across the globe. The four paths for qualification paths are customer, partner, evangelist, or VCDX. In short…..you DO NOT have to be a VMware employee to qualify. If you are still asking what’s in it for you, here are my Top 5!

Connections – For me, I have really enjoyed the bond that comes with meeting other vExperts. We are all passionate about VMware’s vision and technologies and it’s been great to share in this common bond. In today’s remote work environment, it’s been great knowing there are others I can still connect with no matter the distance between us. My circle continues to grow and it makes attending events even more fun as I run into people I don’t get to see very often but the vExpert bond is there. Which leads me to ……..

Community – This is what it’s all about! I have been able to leverage this community to grow professionally. The vCommunity gave me the tools I needed 16 years ago to learn more about products like ESX, View, and VSAN and give me the hands-on experience I needed to deploy ESX “for real” at customer sites. This was the beginning of my VMware journey. As a vExpert, I have been able to contribute to the VMware Technology Network (VMTN) by posting blogs as well as answering questions. While you don’t have to be a vExpert to contribute, it’s one way I have been able to stay active in the community. The vCommunity is AWESOME and what better way to spend time with the community than at…..

Conferences!!! – Who doesn’t want to spend time with the likes of Pat Gelsinger, Michael Dell, Sanjay Poonen, Raghu Raghuram and others?!!! The vExpert party every year (san COVID) is always a great party. As a vExpert, you get the VIP treatment!

Michael playing ping pong!!

In addition, I found that if you like to present at Regional and local UserCons, VMUGs, and other events, being a vExpert can increase your chances as the vExpert Program gives you opportunities to build your brand. This can also lead to a…..

Promotion!!! – In my experience, being a vExpert has allowed me to dig deep into topics I am passionate about such as cloud computing, career development, and mentoring to name a few. My management teams have taken notice over the years and I have been able to leverage my vExpert interactions and experience into being promoted as well as changing roles. That being said, it’s important to OWN your career progression, no one will do it for you. Also, another type of promotion available within the vExpert program is that they will also promote your contributions if you blog, publish books, videos, etc. Lastly, the vExpert has given me some pretty great…..

SWAG!!! – Otherwise known as “Stuff We All Get”.

• Licenses!! As a vExpert you get 1 year licenses for most of VMware’s products for use in your lab environment
• VMworld vExpert SWAG. Every year is different but the vExpert program as well as several partners such as Cohesity, Veeam, Datrium (now VMware Cloud Disaster Recovery) and others provide T-shirts, Raspberry Pi, and many other goodies for you to enjoy!
• vExpert branded items such as Polo shirts, sweatshirts, hats, socks and more via a “pop up” shop

What do I have to do to become a vExpert?

Take time to put together an application, and make it as detailed as possible. The more you enter, the better your chances. The people reviewing and voting on applications are also vExperts that have gone through the same application process. The application is done through an online form found at the vExpert site.

The key for your application is to detail what have you done in the past year in terms of “giving back” to the community. Things that count could be blogging, videos, public speaking, VMUG contributions (i.e. VMUG leadership), book authoring, forum activity, and more.

Help is available!!!!

If you need help or guidance on your application, reach out. There is a vExpert PRO subprogram that consists of a special group of vExperts who can guide aspiring vExperts with their applications and the first steps after becoming a vExpert. Feel free to reach to me as well.

So, what are you waiting for? Apply now! I am!!!!

Policy Routing with HCX Mobility Optimized Networking (MON)

**First and foremost, thank you Michael Kolos for the assist on this blog!!!**

If there is anything I’ve learned over the past four years with VMware Cloud on AWS (also applies to other hyperscalers) it’s that spinning up the SDDC is easy. It’s connecting on-premise and other cloud providers together that’s the hard part. In order to simplify these connections, VMware engineered a little bit of magic with VMware HCX™. In summary, VMware HCX™ is an application mobility platform designed for simplifying application migration, workload rebalancing and business continuity across datacenters and clouds. As a part of an HCX deployment, a few appliances are deployed. HCX Manager, WAN Interconnect (IX)m, WAN Optimization (WAN-OPT), Network Extension (L2C), and a Proxy Host. More details can be found here. For this post, I am going to focus on enabling MON via the HCX Network Extension and why you need to understand policy routing. I’ve run into this a few times with customers. Hopefully, this helps!!

So what is Mobility Optimized Networking?
Mobility Optimized Networking improves routed connectivity patterns for multi-segment applications and virtual machines with inter-VLAN dependencies as those virtual machines are migrated into the cloud. Without MON, HCX Network Extension expands the on-premises broadcast domain to the cloud SDDC while the first hop routing function remains at the source. The network “tromboning” effect is observed when virtual machines connected to different extended segments communicate. More information can be found here.

Scenario: Customer has a Layer 2 network stretched via HCX L2C. In order for the customer to allow their teams to deploy and manage workloads on VMC on a secondary domain, they want to add a Windows Domain Controller as an Identity Source to the VMC SDDC vCenter. This DC is deployed on the same VLAN where the network is stretched. Firewall rules have been validated similar to my previous blog which details the rules needed for the domain controller to communicate with the vCenter. When trying to add the following error appears. F So what gives?!!!!!

Here’s my list of assumptions:

• A source VM, on an HCX L2E network with MON enabled, and the VM set to use the local (MON) gateway – not the source(on-prem) L3 gateway.
• Default policy routes (RFC1918) in place.
• VM trying to reach the vCenter of the local SDDC (i.e. the one where the MON gateway is, not the source L3 gateway)

In this scenario, MON will only optimize the path for other VMs on the MON enabled networks whose gateway is also the MON network, or for routed segments in the same SDDC (connected to the same T1 Router aka Compute Gateway). The SDDC’s management CIDR (which vCenter is a part of) is not connected to the same T1 Route as the vCenter is connected to the Management Gateway. As a result, there is not a matching T1 route. Without this route, the traffic decision then moves to the policy routes. Since the vCenter is using private IP, which is in the default Policy routes for MON, the traffic will be sent back over the L2E to the source L3 gateway. Depending on the routing configuration, this path may or may not work.

To resolve this, we need to modify the default policy routes. Depending on what the desired path is (e.g. what destinations are reachable on the on-prem side), we can update them to match that. The easiest way to do this is to add a DENY route with the SDDC’s management CIDR to the Policy Routes.

In my lab, the SDDC uses 10.62.0.0/16 as the management CIDR, this is how you can add the Policy Route. Go to HCX Manager via the HCX Center Plug-in or HCX Manager URL and select Network Extension > Advanced > Policy Routes.

Enter in the SDDC Management CIDR as a deny rule.

Once this change is made, the Domain Controller is able to communicate with vCenter and is able to be added as an identity source.

Native AWS VPC Connecting to VMware Cloud on AWS (Part 2) – Route Tables and Transit Gateway Attachments

Welcome to Part 2 of VPN connectivity to VMC via AWS VPN. For this post, I will walk through how to attach an AWS VPC to an AWS Transit Gateway in order for route tables to be learned by the VMC SDDC and AWS VPC that will ultimately allow communication from workloads in AWS and workloads in VMC. If you immediately try to ping across the VPN from an EC2 instance to a VMC VM, it will fail as there is more work to do in order to create communication pathways in the form of adding a VPC to the Transit Gateway as well as configure some NSX rules.

In the diagram above I created two EC2 instances with an AWS VPC. For the sake of testing and validation, I first had to create a jump VM with access to the internet in order to remote into the workload VM. This is because, in order for the workload VM to ping across the VPN, 0.0.0.0/0 must be routed through the Transit Gateway and not an Internet Gateway. The goal here is to have a VM on the 10.0.10.32/27 subnet ping a VM on the 10.250.10.0/24 subnet.

To start, the first thing to check is the routing table for the Transit Gateway. This is done by selecting “Transit Gateway Route Tables” on the sidebar with the VPC.

You will then see a list of learned routes from the VMC SDDC. For the sake of this blog, I have deployed AWS EC2 Instances on a subnet that I plan on attaching to the Transit Gateway (10.0.10.0/24). However, notice below that only the learned routes for the VPN to VMC are listed below. While the 10.250.10/0/24 subnet is learned, in order to open communication via the AWS VPC, we first need to attach the VPC to the Transit Gateway so the 10.0.10.0/27 subnet is included. Here are the steps to create the VPC attachment to the Transit Gateway.

Step 1: Select “Transit Gateway Attachments” then “Create Transit Gateway Attachment”. Find correct Transit Gateway ID.

Step 2: Add tag for attachment name.

Step 3: Select the correct VPC and ensure you have the correct subnet selected. Select “Create Attachment”

As you can see, now that the VPC is attached to the TGW, the 10.0.10.0/24 subnet is now listed. This will now allow for the routing of traffic from my EC2 instance to my VM on VMC.

The final step is to create groups and add inbound and outbound firewall rules within the Network & Security section of the SDDC console. Make sure to apply the rule to the VPN Tunnel Interface and NOT “All Uplinks“. The reason for this is that a firewall rule applied to All Uplinks does not apply to the VPN Tunnel Interface (VTI), which is a virtual interface and not a physical uplink. The VPN Tunnel Interface must be specified explicitly in the Applied To parameter of any firewall rule that manages workload VM communications over a route-based VPN. In addition, you can see how groups are created on an earlier blog here.

Now that the routing table is complete and Compute Gateway Firewall rules are in place, you can test!

EC2 Windows VM

Ping results from EC2 VM to VMC VM

VMworld 2021 – 11 Sessions I’m Excited About!!!!

While I’m disappointed I can’t see my coworkers and customers again this year at VMworld this October 5-7, I’m still looking forward to all the great content that will be shared. One of the benefits of virtual is again this year is that it’s free for all attendees! Here’s my Top 11.

VMware vSAN – Dynamic Volumes for Traditional and Modern Applications [MCL1084] – Duncan Epping and Cormac Hogan are at it again presenting their deep knowledge of VSAN in both traditional and modern application use cases. I’m looking forward to see their take on VMware vSphere container storage interface (CSI) in Kubernetes! 

William Lam – App Modernization Deep Dive with VMware Cloud on AWS and VMware Tanzu [MCL2290] – Is VMworld even VMworld without William?! I have been waiting for a long time to talk VMWonAWS and Tanzu!! For those of you who want to see modern apps with Tanzu on VMWonAWS, this session is a must!

Achieving Happiness: The Quest for Something New [IC1484] – Those of you who have met Amanda Blevins know that she’s not only about technology but is also passionate about personal development and brand building. Many things have changed over the past 18 months with our day to day profession and I’m anxious to see what insights Amanda and Steve Athanas (CIO UMass Lowell) will have for us!

A Guide to vSphere with VMware Tanzu: Day 2 Operations for the VI Admin [APP1718] – No doubt Dean Lewis and Simon Conyard will bring their technical acumen and British wit to the session as they cover basic Kubernetes architecture in a way that makes sense for the VI Admin. Kubernetes is a fun word to say, but it’s a completely different thing to say AND do in the enterprise….at the end of the day, you still need to manage the application. These two gents will show you how!

An End-to-End Demo of Day 0 to Day 2 VMware Tanzu Management with vRealize [APP1586] – Matt Bradford and Sam McGeown always create great demos for their sessions. This is a must see for those on the Tanzu and modern application path and want to see how the vRealize suite is making Day 0-2 a cinch.

A Guide to the Cloud Operating Model [MCL1115] – Clouds are becoming the new silos. SaaS can grow your environment exponentially at a rapid pace and before you know it, you’re in the same siloed chaos you were in before cloud. Taruna and Martijn walk you through VMware’s multi-cloud approach when creating a consistent cloud operating model. It’s great to leverage multiple clouds based on specific use cases but it’s important to know how to best manage them.

Design Principles: Cloud Architecture Design and Operations [MCL2151] – Without a doubt these two Principal Architects are some of the smartest people I know at VMware. Mitesh and Andrea have been designing Enterprise VMWonAWS deployment since the service has been available. If you want to know how best to design VMWonAWS for production, this session is #1!

Automate VMware HCX Workload Migration to VMware Cloud on AWS [MCL1050] – This session would be #2 to the one above. Now that you have the VMWonAWS SDDC deployed, it’s time to migrate! Phoebe and Asaf bring their VCDX (between them, they have four!) and HCX knowledge to show you how to automate your migrations.

Cloud Workload Security and Protection on VMware Cloud [SEC1296] – While you’ve migrated workloads to VMWonAWS, you still need to secure them. Being in the cloud does not remove you from needing to protect the asset. Using the security features of NSX on VMWonAWS is a great start. To be even more secure, this panel will show how you can leverage Carbon Black on VMWonAWS.

A Guide to Application Migration Nirvana [MCL1264] – Bottom line….application migrations can be HARD! vRealize Network Insight has quickly become one of the main tools used to help customers understand applications and how to effectively plan for migrations to VMware’s Cloud. Martijn Smit has a wealth of experience to share do be sure to add this to the schedule!!

VMware DRaaS – Combine Two Services for Comprehensive Disaster Recovery Plans [MCL1202] – This session should be awesome! It’s not just about Site Recovery Manager (SRM) anymore. If you haven’t taken a look at VMware Cloud Disaster Recovery (VCDR aka Datrium) yet, you should. This session will cover both solutions and how we’re allowing customers to recover from ransomeware attacks, outages, and more. It’s all about flexibility and this session will give you the information you need to make those critical business continuity and disaster recovery decisions.

I admit that most of these sessions are cloud and application based but that’s where my passion lies and that’s where my customers are headed! Don’t forget to register today and Enjoy VMworld 2021!!!!

Native AWS VPC Connecting to VMware Cloud on AWS (Part 1) – Native VPC Connectivity via VPN

With the release of VMware Cloud on AWS 1.12, we delivered additional connectivity options with the addition of transit connect (VMware managed AWS Transit Gateway). Over the past few weeks, I have been working on a project that has specific success criteria as well as challenges that prevent certain connectivity options so I thought what better way to show how we got around the issue than to show how we did it as Transit Connect and AWS Direct Connect were out of scope. The plan is to have this be a multiple part blog series that details how to setup and test a route based VPN, attach to native AWS EC2 workloads via ENI in the VMC VPC as well as leverage a Transit connect that makes connectivity easier to configure, manage and maintain. The diagram below is the overall architecture for those already leveraging AWS native services via a Direct Connect and Transit Gateway but can only connect to VMC via IPSEC VPN for certain reasons (shout out to fellow VMC Architect Will Lin for the assist!). While Direct Connect provides much better speeds and feeds, you may still be able to accomplish what you need depending on your application requirements.

STEP 1: To get things started, we need to either identify or create a VPC that we want to communicate with the VMware Cloud on AWS SDDC. If you already have a VPC configured you can skip to Step 2. To create a new VPC, log into your AWS account go to Services > VPC> Create VPC. Similar to creating your VMC SDDCm it is paramount that plan your CIDR range appropriately so can assign subnetting correctly based on what you are trying to accomplish. ** Make sure you are selecting the correct AWS Region based on your requirements! **

Next, create a subnet that you will assign to the VPC. This is why understanding the CIDR ranges is important as you cannot have any overlap between your VPC CIDR and VPC subnets so keep that in mind as you build things out.

Creating a subnet assigned to the AWS VPC

Step 2: Deploy a AWS Transit Gateway (TGW). For reference, an AWS Transit Gateway connects VPCs and on-premises networks through a central hub. Keep in mind the default ASN number for the AWS TGW is 64512. If you are going to use an existing TGW, get the correct number from your team. For the sake of this blog, I setup the TGW with all the default settings.

Step 3: Create a Customer Gateway (CGW). A CGW is a resource that you create in AWS that represents the customer gateway device in your on-premises network, or VMC in this situation. 

In order to configure the CGW, you need to enter the VPN Public IP listed in the Networking & Security section of the SDDC console.

Step 4: With your transit and customer gateways configured, it’s time to create the VPN connection from the AWS side. Go to Services > VPC > Site-to-Site VPN Connections > Create VPN Connection. Name the VPN connection and select “Transit Gateway” as the gateway type and add your CGW. Take note that you can also add a new CGW didn’t as a part of the previous steps. We want to set the routing options to dynamic so we take advantage of BGP. My personal preference is to define the CIDR and per AWS documentation, this needs to be a /30 within a certain range. I also created a basic preshared key rather than have AWS create the key randomly.

AWS VPN Configuration

Step 5: Download the VPN configuration as a generic file. This is where you can validate the configuration and use it for configuring the VPN from the VMware Cloud SDDC Console.

Step 6: Configure the VPN on the SDDC. Go to the VMC SDDC Console > Networking & Security > VPN > Route Based > Add VPN. Here you want to take the Virtual Private Gateway Outside IP and enter that into the Remote Public IP Field. Take the Customer Gateway Inside IP Address and enter that number as the BGP Local IP. Next, take the Virtual Private Gateway Inside IP and enter that into the BGP Remote IP field. All that’s left is to enter the BGP ASN number that your configured earlier as a part of the TGW creation. It should also be listed in the config file you downloaded. If all numbers are correct, you should see the VPN Tunnel and BGP come up in a matter of minutes! If the VPN comes up and BGP does not, check your IPs and ASN numbers. Additional help can also be found here!!!!

You now have a working VPN from AWS to VMC!!! While the tunnel is up, there is more work to do so you can fully test traffic. In Part 2 I will cover routing tables and SDDC Gateway rules to enable two way communication. Stay tuned!!!!

Same Place, New Beginnings!

A few months ago, I decided to take a calculated risk and explore other roles within VMware. Up to this point in my career, a new role meant moving on from the organization as well. The experience of moving within a company the size of VMware is a bit different and while I will miss the customers and team interactions, I am excited for my new role as a Cloud Solutions Architect!

I have dedicated much of my free time over the past four years to all things “cloud” and it has opened several doors of opportunity which has ultimately led to me filling this role. In working with enterprise customers, there is an appetite to get out of managing datacenters and shift focus to creating applications that differentiate themselves from the competition. Enterprises no longer want to maintain their monitoring, alerting, and back up tools; thus shifting to a Software as a Service (SaaS) model. I’m passionate about helping others succeed. This role allows me to work with customers who want to better understand what “cloud” means to them and how VMware can help them realize (see what I did there?…sorry Dad joke) their business and IT outcomes.

On a personal note, I have worked with a few mentors over the past 18 months who have challenged me to push even further outside of my comfort zone which has been unsettling at times but I have found that doing so helps me to stay sharp and push myself to do things differently. For those looking to change it up as well I recommend the following:

• Follow Your Passion. No use in doing things you don’t enjoy.
• Take time to assess where you are and where you want to be.
• It’s ok to say “No”. I was fortunate enough to receive a few offers on this journey but I had to follow my passion despite some of the offers were fantastic opportunities.
• Be open with your management. Management should be there to help you achieve your goals, if they are not supporting you…..it’s time to move on anyway!!
• You are going to need to put in some effort after hours if you want to change directions.
• Ask for help

I’m looking forward to the next chapter and even more opportunities to talk cloud with you all!

Mini-Blog – VMWonAWS vCenter Certificates

For the last several months, I have been working with customers as they upgrade their SDDCs. One of the more impactful Day 2 activities that occurs during these upgrades is a the updating of vCenter and NSX certificates during Phase 1. During my time as an Engineer, we would keep certificates for 3-5 years as a part of our lifecycle management as we were 100% on premises. In contrast, many cloud providers are beginning to set certificate expiration to one year. This a faster rate of change than what many are accustomed to who manage on premises datacenters. While VMC manages these SDDC certs for you, many customers have asked me how they can continue to pull the cert expiration info so it can still be documented internally. Here is a simple openSSL command that can be run via Github. Trying something new!! FYI, this command needs to be run via a Linux VM that can access vCenter via IP or FQDN. Hope this helps some of you!!

Day 2 VMware Cloud on AWS SDDC Scale Up…in Four Clicks or Keystrokes!!!!!

As customers continue to build their cloud strategy with a combination of VMware products and services, one thing has been heard loud and clear…”Make Day 2 Operations easy!” As customers continue to move and increase their footprint in VMWonAWS, the SDDC’s demand for management resources will increase. While the VMC Sizer is a great tool to help understand the recommended size of an new SDDC, there will be times when SDDC growth is too big for the management VMs to handle after the SDDC is deployed…kind of like the time when Sheriff Brody realized he was going to need something much larger to catch a Great White shark.

When an SDDC is created, two resource pools are created. One named “Compute- ResourcePool” and one named “Mgmt-ResourcePool”. Mgmt-ResourcePool (MRP) is VMware managed and is comprised of vCenter, 2 NSX Edges, and 3 NSX Managers by default. In order ensure uptime and performance, all resources in this MRP have reservations assigned so these appliances always have what they need.

For more information, Product Manager Vish Kalsi wrote a quick blog on choosing the correct SDDC deployment. In short, medium management appliances require 34 vCPU and 116GB memory to run vCenter, NSX Manager and other management appliances. Large management appliances require 68 vCPU and 240GB memory. Large SDDCs are ideal for addressing a larger density of workloads . Large SDDCs support enhanced network throughput on the NSX Edge appliance. VMware recommends large-sized deployments with more than 30 hosts or 3000 VMs, or if the resources (CPU or memory) are oversubscribed in the management cluster.

Previously, a VMware support ticket needed to be opened in order to convert a regular aka medium SDDC to large. This method was obviously not preferred by most as this is the opposite of a self-service cloud operation model. However, begging with VMWonAWS 1.10, you can now upscale your SDDC to large with just a few clicks….or keystrokes!!!

Start by logging into the Cloud Services Portal, select your SDDC and go to Settings > SDDC > Management Appliance. You will see your SDDC as well as the “Upsize” option listed as seen below.

Upsize Option within the Cloud Services Portal

The only thing left to do is accept the addition of hosts if necessary and understand that you can never go back to a regular size SDDC. Once Upsize is selected, the process takes about 2 hours to complete and you will lose connectivity. It is recommended to do this during a maintenance window.

Once complete, the Management appliances will reflect as a “Large”

Once, in vCenter, you will see that the NSX Edges have gone from 4 CPU x 8 GB RAM to 8 CPU x 32 GB RAM and vCenter has gone from 8 CPU x 28 GB RAM to 16 CPU x 37 GB RAM (only 12 of the 16 CPUs are reserved in this configuration). You can check the before and after in the VM summary as seen below.

Regular SDDC vCenter

Large SDDC vCenter

Now that the SDDCs have been upscaled, it’s onto bigger and better things for your VMWonAWS SDDC!

Embrace the “New Normal”

“The only constant in life is change” -Heraclitus

Being in IT for 15+ years I have seen many things change from 3.5″ floppy discs to 64 GB microSD cards and from the Intel i486 processor to ARM Coretx-A72 processors found in Raspberry Pis. To take it a step further, my foray into IT was more of a trial by fire than a chosen profession. Back in my college days I worked for a small start up as a project manager for a call center that provided customer support and telesales. Due to our size, we all filled many roles and as we on-boarded handfuls of new reps every few weeks, yours truly was responsible for setting up PCs. That means physically setting them up to use….not configuring roaming profiles or any type of OS configuration. I mean plugging in keyboards, mice, and monitors via PS/2 and VGA connectors. I still to this day don’t know why I chose the path that I did but there was something about tearing things down and rebuilding them that peaked my interest. Due to our size and budget, there were several occasions where we cannibalized two mediocre PCs to create one that was one step above mediocre. Fast forward a few years and I’m CompTia A+and Network+ certified working my way towards a Microsoft Certified Systems Engineer (MCSE).

Why do I bring this all up? First, the best way to further your IT career is to be curious. Second, as I have been working with several enterprise and commercial customers over the past six years, I see the need for VI administrators and system administrators to rapidly expand their skill sets to remain relevant and valued within the organization.

Scripting

I will be the first to admit that I am not a developer. With a heavy windows background, I have always preferred a GUI since lines reading lines of code was very foreign to me. That being said, as I grew more comfortable with system administration via Windows, I became more curious around how I could automate more of my daily tasks via scripts…enter the login.bat file for Windows user profiles! While it wasn’t exactly complex, it still gave me an entry point to learn how to automate small processes that saved me a lot of time. Hopefully most of us rely heavily on scripts and are using tools such as PowerShell. If you aren’t, you should!

With my Windows background, CLI based operating systems such as Linux and IOS scared me to death! I had no idea how to start and the closest thing I could compare it to was MS-DOS back in my early gaming days when the original King’s Quest was released. It wasn’t until working with ESX, Cisco, and OpenBSD for customer projects where I started facing my insecurities around CLI and discovered it wasn’t as intimidating as I once thought. While I don’t think I will ever be a developer or coder, I can unequivocally state that getting comfortable with CLIs within ESXi and NSX is a MUST for any VI admin. My first recommendation is to head over to VMware {code} and get started with PowerCLI! Once you become more familiar with PowerCLI, don’t spend all of your time writing your own scripts. PowerCLI guru Alan Renouf has a litany of scripts that may be of benefit. He has created scripts for VMs, Storage, Hosts, reporting and more!

APIs

Application Programming Interface (API) is quickly becoming a necessary skill set for any administrator or engineer. Being able make API calls (requests) to applications and services takes the ability to programmatically administer environments to another level. Over the past several years, VMware has worked hard to create REST (REpresentational State Transfer) APIs to allow developers and VI admins alike to better automate on several levels. In addition, there are some features with VMware services that can only be done via API or are released in the API first and then the GUI follows. A full list of VMware APIs can be found here. If you come from an operations background like me, you may prefer a GUI tool to assist when getting started with APIs. I have found Postman to be beneficial. To get things started, I have included two videos that should help get you started. The first is a vBrownBag session from Kyle Ruddy who walks through vSphere APIs with Postman.

The second is an introduction VMware Cloud on AWS.

Leveraging APIs are the new normal. If you are a VMware Cloud on AWS customer, take time to dig into the Developer Center and start playing with the API explorer and Code Samples! Two more great resources for leveraging VMware APIs are Patrick Kremer and William Lam. Truth be told, if there is an API question that I can’t answer, William always seems to have it!

VMware Cloud on AWS Developer Center

I am new-ish to this way of life but really enjoy learning new skills! If you are in tech, it’s a lifetime of learning so we all should embrace it with excitement. I hope to post more about my learnings and possibly even share some code samples but until then….click through all the links above and get started!!!

Effectively Planning VMware Cloud on AWS SDDC Upgrades

One of the questions I am often asked is now that I am using VMware Cloud on AWS, how do I go about managing my SDDC life cycle? The answer…..VMware has you covered! As of March 2020, we have made some significant enhancements to the Notification Gateway (NGW) that give you several options to receive updates from VMware Cloud Services regarding maintenance activities such as certificate replacements and SDDC upgrades to new releases. While the NGW can be leveraged in several different areas, my preferred integrations are with Slack and Microsoft Teams. Setting up these integrations are fairly straightforward. Look no further than William Lam’s blog for details.

Even if you have Webhook integrations setup, you will still get a notification email similar to the image below letting you know when your SDDC is scheduled for an upgrade.

Notification email from Notification Gateway detailing each phase of the SDDC upgrade.

It is imperative that you take note of the dates and times your SDDC is scheduled for each phase as your times will all be in UTC timezone so do your time conversions accordingly. When you login to your SDDC console and go to the maintenance tab and you will see each phase listed along with recommendations for each phase.

Each phase of the SDDC is highlighted below as well as details around SDDC accessibility during the upgrade. For detailed information, read my associate Tom Twyman’s blog and the SDDC upgrade notes found here. We continue to improve upgrade processes in the background so check back often!! There are additional considerations to make when integrating with HCX, Site Recovery and Horizon so be sure to understand the impacts listed in the read me!! Keep in mind that during Phase 1 your vCenter certificate will be updated and the NSX certificate will be updated during Phase 3. If you have other products and services that depend on vCenter, you will need to take the proper steps to accept the new certs.

While there are time estimates for each phase, mileage may vary during the upgrade. To make things a bit easier for you. I have included a simple excel spread sheet to help you plan your SDDC upgrade.

sddcupgradescheduleDownload

After going through several customer upgrades over the past two years, my top 5 things to do are

1. Don’t forget about certificate validation afterwards!
2. Plan your outages around each phase and best to be conservative. Allot for the full estimated time.
3. Setup integrations with the NGW. While emails are nice, it has been my observation that people get too many emails these days and these notifications are often ignored. Pick a delivery method that will get your attention!
4. Read the release notes as well as upgrade notes before your scheduled upgrade.
5. Don’t panic! For some, giving VMware the keys to the car (SDDC) is unnerving, and they want to watch and be involved. Remember this is a service, we have you covered. Sit back and relax!