Update VMware vCloud Director 9 in 5 Minutes

I sometimes hear that vCloud Director (vCD) is cumbersome and hard to install/upgrade. I just updated my lab environment vCD instance from 9.0 to 9.0.1 in about five minutes. The team has done an incredible job of making any patch/upgrade process seamless. Below are the steps for upgrading while documentation link is below.

Upgrade VMware vCloud Director Installation – Documentation

We can see I’m running the 9.0 base version. As stated above, we will upgrade to 9.0.1.

Download and check integrity

  1. Go to vmware.com and download the latest upgrade package 
  2. Upload via SCP (or your method of transfer) to your vCD cell 
  3. Now let’s SSH to our vCD cell and check the md5sum to ensure nothing happened from downloading it to copying it. Yes, md5 matches and we are good! 
  4. Let’s go ahead and make the bin file executable. “chmod u+x <filename>” makes it easy and now we can see it’s executable. 

Run the Installer

  1. We are now ready to run the vCD installer bin file. Let’s go ahead and dot slash it! 
  2. The installer will verify you have an upgradeable version of vCloud Director and ensure you want to proceed with the upgrade. Type “y” to continue on. 
  3. Now we can see the installer is stopping the vCD cell processes and continuing on with the installation.
  4. And we are complete! The last message we see is we need to perform the database upgrade to ensure the schema is up to date. 

Update the vCloud Director Database

  1. Okay, let’s go ahead and run “/opt/vmware/vcloud-director/bin/upgrade” – we see a message ensuring you want to continue with the upgrade. You’ll want to make sure all of your other cells are stopped to ensure there’s no database connections. 
  2. The upgrade will look at the database and ensure everything is acceptable. Again, you’ll one more time, just to make sure you have that backup! 🙂 
  3. we can see the upgrade task was completed and everything looks great. We are prompted to start the vCD services back up. Type y to continue on. 
  4. Services are started! 

Let’s log in and check the build version. There we go, on the latest version of vCloud Director 9.0!

That’s it. Very easy and straightforward. If you’re interested in further insight on architecting vCloud Director, do check out our free vCloud Architecture Toolkit papers:

Thanks!

-Daniel

vCD Extender – Warm Migration Video

This will be my last post on vCD Extender – an exciting addition to vCloud Director and wanted to provide a comprehensive look at Extender’s functionality.

Link to vCD Extender Warm Migration Setup – Part 1 of 2

Link to vCD Extender Warm Migration Setup – Part 1 of 2

Link to vCD Extender Warm Migration Demo Walkthrough

With this video, I created a new VM called WebApp3 and plan to migrate it over to the vCD Cloud environment. I’ve updated my logical demo diagram to the following:

Here’s the video I recorded – enjoy!

vCD Extender – Warm Migration Demonstration

Continuation of vCD Extender Setup – Part 1 and Part 2

Now you’re ready for your first migration. Going back to my high-level diagram, I will be migrating WebApp2 to the Provider vCD environment and ensuring connectivity is available over the VPN tunnel.

Before we start, we can see WebApp1 can ping WebApp2:

Let’s go to Migrations – Warm Migration:

Let’s select WebApp2 – remember, it must be running for a warm migration:

Selecting the defaults – I only have one network here, so it defaulted to our L2VPN network of “company-network”

Changing the Target RPO to 5 minutes (this is the fastest RPO currently) and naming the migration job “WebApp2-Migration” – this will start immediately.

Okay, now we see the job running! Depending on your network connectivity, this will take some time to replicate over the WAN.

So let’s see what happens behind the scenes.

On my provider side, I see my cloud replication instance accepting the incoming replication:

We can also see on the provider vCenter, a shell VM is substantiated and then removed from inventory. I also see some kind of SSL update to one of the hosts (I presume this is to allow direct replication):

On the tenant side, I can also see a task in here to enable and start replication of WebApp2:

While the On-Prem replication instance shows an outbound replication ID:

OK, initial replication is complete! We are now ready to cut WebApp2 over.

Back to Workloads subtab -> hit the Start Cutover button

It will prompt you for the target and you can also choose to power it on after cutover. This is handy if you had multiple VM’s that were ready for cutover, but perhaps not ready to cut them over at the same time.

Hitting the start button, you are asked one last time if you’re ready to cut over…

Alright, we are cutting over…

We can see the pings stop…

We can see WebApp2 was shut down –

I start seeing some new tasks on the provider vCenter side…

Now we also see WebApp2 pop up in vCD –

Looks like we have power on!

And now waiting a few moments for the VM to fully boot…and we have connectivity! Note that I am double nested here, so this duplicate packet behavior is something I’ve seen with VPN tunnels. 

WebApp1 can see WebApp2, let’s see if it’s the reverse! Yes, we do.

By my count, this took about 4 minutes from me pushing the button, final synchronization and having network connectivity between my two WebApp servers.

I hope to have a demo video next – enjoy setting up vCD Extender and migrating your customers to your vCD Cloud! #longlivevCD

-Daniel

vCD Extender – Warm Migration Setup – 2 of 2

Continuation of vCD Extender – Warm Migration Setup – 1 of 2

3. Configure L2 Appliance configuration inside of tenant Extender Appliance

Alright, now we are ready to set up the DC Extension on the tenant side. First, we need to tell the tenant Extender appliance where to position the L2VPN-Client edge in the tenant environment.

First, let’s log into the Extender tenant appliance:

Click on DC Extensions and Add Appliance Configuration (top button) – remember, our tenant does not have NSX (but could as you see below!) so we will have Extender deploy a standalone L2VPN Client edge.

Now let’s put in the configuration parameters for the L2 Appliance. As you can see, this is for my “Company-Network” so I set its IP, default GW, and the prefix length. Make sure you hit the Add button before hitting Create:

Ok, great, now we have an L2 Appliance Configuration:

Next, let’s get into the Plugin and establish our DC Extension.

4. Establish DC Extension in Extender plugin

Last step before we can start migrating! This is assuming you have your provider cloud established – let’s now go to DC Extensions

Click on New Extension –

Put in a name, source info (you can see I selected my Company-Network) and Destination will populate your vDC along with the subinterface Network. If you do not see any Network, something went awry with the trunk interface, check it out.

Also, note that we added the local Egress default gateway IP to enable the L2VPN-Client to route any packets sent towards the Egress Optimization IP address locally, and send everything else over the tunnel. If the default gateway for the virtual machines (belonging to the subnets you’re stretching) is same across the two sites you will need this setting to ensure traffic will be locally routed on each site. Should you need to migrate VM from one site to the other, you can do so without changing the network configuration on the guest VM and hence the mobility.

Now click that Start button…

Now we will see the status as Connecting…

So what’s happening in the background? Well, Extender is now deploying the L2VPN standalone edge and also creating a Distributed Port Group for the sink traffic:

On the Provider side, what do we have here? We have a new site config under the L2VPN-Server:

Really slick! So Extender automatically creates a new config based on this configuration.

Going back to the tenant, I see the IP was set to the L2VPN-Client Edge and the sink port was configured completely:

Taking a closer look at the DVS port Extender created, we can see Promiscuous Mode and Forged Transmits were set to Accept:

Oh, and look at that – it’s Connected! Woohoo!!!

On the Provider NSX side, we can see the tunnel is up and kicking:

COMPLETE! You are now ready for your first warm migration.

Again, big thanks to my buddy Wissam for the collaboration here.

Next – let’s do a warm migration!