Getting Started With Oracle Cloud VMware Solution (OCVS) – Networking Configuration

In my recent ‘Getting started with Oracle Cloud VMware Solution (OVCS)’ post; Getting Started With Oracle Cloud VMware Solution (OCVS) – Deploying The SDDC With HCX we deployed ourselves a Software-Defined Data Center (SDDC) along with VMware HCX into Oracle Cloud. In this post, I’m going to review the overall networking configuration, including NSX-T.

ESXi Host ‘Oracle Cloud’ Connectivity

First, let’s take a look at how the ESXi Hosts are connected to the Oracle Cloud infrastructure.

  1. Login to the OCVS console
  2. Select the correct Region. (This should be the same region that the SDDC and the Bastion host were deployed)
  3. Click on the burger icon at the top left of the screen to display the menu
  4. Scroll down on the left-hand side menu and select VMware Solution
    • Select the name of your newly deployed SDDC
    • Scroll down to the ESXi Hosts section
    • Select one of the ESXi Hosts (Compute Instance column)
    • Scroll down to the Metrics section
    • Select Attached VNICs on the Resources menu (left-hand side of the page)

OCSV - ESXi vNICs

Here we can see virtual network interfaces, Subnets, and VLANs that are attached to the ESXi Host. The following diagram illustrates a single ESXi Host’s connectivity to the various VLANs deployed as part of the SDDC configuration. As we go through the networking configuration, the diagram will begin to make more sense.

OCVS - ESXi Connectivity
Read the rest of this entry »

Getting Started With Oracle Cloud VMware Solution (OCVS) – Deployment Overview

In the most recent ‘Getting started with Oracle Cloud VMware Solution (OVCS)’ post; Getting Started With Oracle Cloud VMware Solution (OCVS) – Deploying The SDDC With HCX we deployed ourselves a VMware vSphere Software-Defined Data Center (SDDC) along with VMware HCX into Oracle Cloud. In this post, I’m going to do a high-level review of the SDDC deployment which includes the VMware vSphere components (vCenter, ESXi Hosts), NSX-T Manager, and VMware HCX. Subsequent posts will dive deeper into the configuration.

SDDC Deployment Overview

OCVS - SDDC 

  1. Login to the OCVS console
  2. Select the correct Region, this should be the same region that the SDDC and Bastion host were deployed into
  3. Click on the burger icon at the top left of the screen to display the menu
  4. Scroll down on the left-hand side menu and select VMware Solution
    • Select the name of your newly deployed SDDC

We are now presented with the SDDC information. This page contains all of the important URLs, IP Addresses, Usernames, Passwords that you’ll need to access and manage your environment.

OCVS - SDDC Details
Read the rest of this entry »

Getting Started With Oracle Cloud VMware Solution (OCVS) – Deploying The SDDC With HCX

Following on from my recent post; Getting Started With Oracle Cloud VMware Solution (OCVS) – Deploying A Bastion Host which documents the steps needed to deploy a bastion host on Oracle Cloud, that will be used to access our OCVS SDDC. We can now deploy the SDDC, including VMware HCX (optional).

As you will see, the deployment process is very simple and straightforward. Once we have successfully deployed the SDDC and HCX, in the next blog post in this series, we’ll take a closer look at how the solution is deployed within Oracle Cloud.

Prerequisites

  • SSH Keys
    During the deployment of our bastion host, we created a set of keys (public and private) that were used to access the bastion host via SSH. The same approach is used with the ESXi hosts in the SDDC. Instead of providing a root password, we need to supply our public key.

Deploying the SDDC

OCVS - Select VMware Solution
Read the rest of this entry »

VMware Cloud Foundation Public Cloud-Hosted Services

In the past few months, there has been a surge in public cloud providers announcing their hosted VMware Cloud Foundation services. Here are a few examples:

In an attempt to try and keep up with the various cloud services that are becoming available, I’ve created the following page: Comparison: Public Cloud-Hosted – VMware Cloud Foundation Services to help me learn more about each individual service offering. Data on each service has been collected in order to have data points from all service providers available in a single place.

At the moment, the table includes information from the following cloud services:

The page will evolve over time as new services/features become available, so follow me twitter @Simonlong_ for updates. If a cell is empty it’s because I haven’t been able to find the information yet. If you notice any incorrect information, please contact me via twitter @Simonlong_ and I will do my best to update ASAP.

What is Datrium ControlShift?

Recently, Datrium has made a series of announcements, one being the introduction of our new product called ControlShift.

Following on from my previous post, ‘What is Datrium DVX?‘ and ‘What is Datriun CloudDVX?‘ I’ll explain in simple English what CloudShift is and highlight some of my favorite features.

Datrium ControlShift

ControlShift is a cloud-based, workload, and disaster recovery (DR) orchestration service. Using DR Plans (run-books), workloads, and data to be easily moved and/or recovered between multiple on-premises environments and/or VMware Cloud on AWS.


Datrium ControlShift

Like CloudDVX, ControlShift is a SaaS service managed by Datrium running in AWS. Customers do not need to install/manage/upgrade additional software, this is all managed by Datrium. For DVX customers, once ControlShift is enabled, it is seamlessly integrated with the Datrium DVX vCenter Plugin, shown below.

ControlShift Button

For non-DVX customers, ControlShift is accessed via a unique customer URL. Once logged into ControlShift, we are presented with the ControlShift Dashboard

Datrium ControlShift Dashboard

Within the CloudShift Dashboard, we can see an overview of the whole Datrium environment. We can see all of our vSphere Protected Sites, our DVX systems, our CloudDVX instance and if deployed, our VMware Cloud on AWS SDDC. The arrows between the sites in the Topology diagram illustrate the direction of replicated data between sites. In this example, all sites are replicating to CloudDVX. However, replication between on-premises is available when using Datrium DVX. Having data replication between sites and the cloud allows us to be able to quickly move workloads between sites or bring up workloads in the event of a site failure.

ControlShift Dashboard
Read the rest of this entry »

HCX Manager on ‘VMC On AWS’ Is Not Available After Deployment

I’m just putting together this short post more for my own benefit more than anyone else’s. This has happened to me a few times, so I wanted to document it down somewhere so I don’t forget it again.

After deploying HCX within VMC on AWS, I am unable to access the public HCX Manager URL.

HCX Manager Unreachable
After speaking with the VMC on AWS support team, they informed me that I needed to add a Firewall entry to the Management Gateway Firewall.

HCX Management Gateway Firewall Rule
The rule configuration was as follows:

  • Name: HCX External Access (you can name this whatever you wish)
  • Sources: ANY
  • Destinations: HCX (this is a predefined entry)
  • Services: HTTPS (TCP 443), ICMP (Echo Request)
  • Action: Allow

Once the Firewall rule was published, I was able to access HCX Manager. Hopefully, they’ll automate this process in the future or add it to the documentation somewhere.

HCX Manager Login Page

vMotion Error – Failed to receive migration

I recently ran into a situation, when after adding a new ESXi Host into a vSphere Cluster that will be used for Nested ESXi, I was unable to vMotion live VM’s onto the new Host. The error message I was getting was ‘Failed to receive migration’

A quick Google search didn’t yield any results, so I had to resort to reading the logs. In the Virtual Machine log file (vmware.log) I noticed this error message: (Scroll to the right)

2019-01-10T20:31:06.254Z| vmx| I125: Msg_Post: Error
2019-01-10T20:31:06.254Z| vmx| I125: [msg.cpuid.vhv.enablemismatch] Configuration mismatch: The virtual machine cannot be restored because the snapshot was taken with VHV enabled. To restore, set vhv.enable to true.

Doing a quick search of the term: vhv.enable showed me that this is required to be set on hosts that are being used for Nested ESXi. Thanks William Lam (https://www.virtuallyghetto.com/2012/08/how-to-enable-nested-esxi-other.html)

So I ran the following command on the new ESXi Host:

echo 'vhv.enable = "TRUE"' >> /etc/vmware/config

After that configuration was added to the config file, vMotions began to function as expected.

Quick And Easy Replication For VDI Golden Images

Continuing on from my previous post; Backup, Restore And Replicate App Volumes, AppStacks And Writable Volumes another large challenge I faced running a Global Enterprise VDI environment was managing the Golden Images.

Replicating VDI Golden Images

The Challenge of Golden Image Replication

For those of you who might not be familiar with VDI environments, Golden Images are the virtual machines that virtual desktop pools are created from. If you need to add an application or make an OS customization for all of your end users, typically you will make the change in the Golden Image and then push that image out to the virtual desktops.

When a VDI environment consists of multiple sites, each separate site usually has its own instance of VMware Horizon or Citrix XenDesktop/XenApp. Each of these separate VDI instances will need their own Golden Images from which virtual desktop pools will be created. In an ideal world, being able to use the same Golden Images for all desktop pools regardless of which site they are in would make the most sense as typically the Pools are the same between sites and this will keep desktop images consistent for all end users. However, until now, this has proven difficult to achieve.

In legacy HCI environments, the replication of virtual machines is very difficult and painfully slow. The main two replication options we see being used are:

  • vSphere Content Library – Using the built-in Content Library service, vCenters can be linked to provide the replication of Golden Images between vCenters
  • Manual Export/Import – Using vCenter to export the Golden Images into an OVA/OVF template, manually copying them to the remote sites and then importing the template into vCenter

There are, however, downsides to both of these methods. In both cases, the whole Golden Image is being replicated each time an update is made. If an image is 60GB in size and there are three remote sites, that’s quite a lot of data that needs to be transferred, this usually is a very slow transfer process and can put a heavy strain on the WAN infrastructure. Additionally, when these images are copied between sites, the vSphere Snapshots are lost in the process making it very difficult to roll changes back if there are issues as all snapshot history is lost.

Golden Image Sprawl

Because of these replication challenges, what we end up seeing is Golden Image sprawl, configuration drift, and an inconsistent-user user experience. Each site has its own set of Golden Images, which are similar to the other sites, but over time the configuration of these images deviates from the other sites. These additional Golden Images also add operational overhead. Each image will need to be patched and kept up to date. The more images you have, the harder it is to keep track of them and the longer updates take to roll out.

Quick And Easy Replication using Datrium DVX

It shouldn’t be this painful. It doesn’t need to be this painful! Using Datrium DVX it only takes a few clicks to replicate Golden Images between multiple sites. The following video (5 minutes) is a brief demonstration of how simple it is to replicate a new snapshot on a Golden Image to a second site.

Some of the key benefits to understand are:

Deduplication and Compression – DVX uses the always-on global deduplication and compression service to only send the changes made to the Golden Image. Rather than sending the whole virtual machine, DVX will only send the data that has changed. This dramatically improves replication times and reduces the load on the WAN infrastructure.

Persistent vSphere Snapshots – When Golden Images are replicated between sites, so are vSphere snapshots. So each Golden Image will show the same snapshot history, regardless of the site they are in. This makes it a lot easier to rollback and forward changes.

Backup, Restore And Replicate App Volumes, AppStacks And Writable Volumes

no problemOne of the biggest challenges I faced running VMware’s internal Horizon environment, was being able to backup, restore and replicate Writeable Volumes and AppStacks. Not being able to backup and replicate Writeable Volumes meant were unable to use Writables to capture our user’s data as we were unable to copy the data to an offline backup array for archive or replicate the data to our other data centers to be used in the event of a site failure.

This is no longer a challenge using Datrium DVX.

App Volumes

App Volumes is a product offered by VMware that has two main features:

  • AppStacks – Packaged applications that get connected/disconnect to a user’s virtual desktop during login/logoff.
  • Writable Volumes – Virtual disks that get connected/disconnect to a user’s virtual desktop during login/logoff. These virtual disks capture any changes made to the virtual desktop, giving a persistent user experience in a non-persistent VDI environment.

If you are not familiar with App Volumes, have a look at this great video – VMware App Volumes Technical Overview

Both AppStacks and Writable Volumes live their lives as VMDK files. This makes it very easy to connect/disconnect them to virtual machines during the login/logoff process. However, there is a massive downside to using VMDK files. AppStacks and Writeable Volume VMDK’s are not permanently associated with a virtual machine, which makes it is almost impossible to back them up using traditional vSphere backup software. Due to limitations in the vSphere API, traditional backup solutions can only back up virtual machines and virtual disks connected to the virtual machines. If a VMDK is not connected to a virtual desktop, it cannot be backed up at scale…. Until now.

Datrium DVX

Backup and Restore Writable Volumes and AppStacks

Running your Horizon environment on a DVX platform makes backing up and restoring App Volumes AppStacks and Writable Volumes almost a single click process. Don’t believe me? Check out this video I recently captured showing the backup and restore of a Writable Volume.

Replicate Writable Volumes and AppStacks

Replicating Writables and AppStacks is also just as easy as backing up and restoring them with Datrium DVX. I’ve also created another video below to show you how simple this process is.

Summary

Using the built-in Snapshot and Replication functions of Datrium DVX will make the management of your App Volumes deployment extremely simple and straightforward. I really wish I had this technology available to me when I was running VMware’s global VDI environment as I’m pretty sure I’d have a few less gray hairs than I do now 😉

Harnessing The vCommunity To Further Your Career

Over the past 10 years, I’ve been a part of this amazing community. Without this communities support, I wouldn’t have landed my dream job as a consultant within VMware, nor become a Double VCDX. At VMworld 2018 this year, I was lucky enough to spend 20 mins talking to the vCommunity about how they can harness the vCommunity to help further their career. This session was recorded and made available online. In this session, I will share my story and highlight ways that you too can leverage our community to help you reach your career goals and aspirations.

I hope you find this useful. Feel free to message me on Twitter if you have any questions on the content or want to discuss things further.