WilliamLam.com

Cross vCenter Clone with vSphere 6.0+

by // 4 Comments

Similar to the Cross vCenter vMotion (xVC-vMotion) feature that was introduced in vSphere 6.0, Virtual Machine cloning can also be performed across two different vCenter Servers, regardless of their deployment type or SSO configurations. If vCenter Servers are part of an Enhanced Linked Mode (ELM), then a xVC-Clone operation can be initiated using the vSphere Web Client. However, if the vCenter Servers are not part of the same SSO Domain, then you will need to use the vSphere API to perform the operation similar to an xVC-vMotion.

Right before the holiday break, I had a few inquiries on providing some sample code that could demonstrate the Cross vCenter Clone (xVC-Clone) operation using the vSphere API. With that, I have created a new PowerCLI script called xNew-VM.ps1 which does exactly that and should feel familiar for anyone who has used my xMove-VM.ps1 script before. Before getting started, be sure to familiarize yourself with the requirements and supported configurations for xVC-Clone operations, which can be found here and here.

The script contains a number of variables that will need to be defined based on your specific environment. The following variables below pertain to the "source" vCenter Server from where you wish to initiate the clone operation from:

$sourcevmname = "PhotonOS-02"
$sourceVC = "vcenter65-1.primp-industries.com"
$sourceVCUsername = "*protected email*"
$sourceVCPassword = "VMware1!"

The following variables below pertain to the "destination" vCenter Server from where the cloned VM will be deployed to:

$destvmname= "PhotonOS-02-Clone"
$destVC = "vcenter65-3.primp-industries.com"
$destVCUsername = "*protected email*"
$destVCpassword = "VMware1!"
$datastorename = "vsanDatastore"
$datacenter = "Datacenter-SiteB"
$cluster = "Santa-Barbara"
$resourcepool = "MyRP" # cluster property not needed if you are using RP, useful for VMware Cloud on AWS
$vmhostname = "vesxi65-4.primp-industries.com"
$vmnetworkname = "VM Network"
$foldername = "Discovered virtual machine"
$switchtype = "vss"
$poweron = $false #optional
$snapshotname = "pristine" #optional

The last two variables are optional which merely controls whether the cloned VM is powered on and whether the source VM is being cloned while running, in which case, a snapshot is required.

Below is a screenshot of my two vCenter Servers, where vcenter65-1 is my "Source" and vcenter65-3 is my "Destination. I have a VM called PhotonOS-02 which is powered on and I have already taken a snapshot which I have named "pristine". I will then perform a xVC-Clone of the VM to the "Destination" vCenter Server and the new VM will be called "PhotonOS-02-Clone".


Once you have updated the script, you can simply execute it as shown in the screenshot below.


If we now head back over to our vSphere Web/H5 Client, we should now see the xVC-Clone operation start and shortly after (depending on the size of the VM being cloned), it should eventually appear on the destination vCenter Server that was specified in the script.


For quick and small deployments of a few VMs, the xVC-Clone feature can be quite handy. However, if you plan to deploy more than a couple of VMs, it would be more efficient to setup a vSphere Content Library which can configured to automatically sync all or specific content to the destination vCenter Server(s), which will help speed up deployment. I should also point out that cloning from vSphere 6.5+ from onPrem to VMware Cloud on AWS (VMC) also works and is fully supported in both direction which the vMotion/Provisioning PM had just shared with me. For VMC usage, you will need to ensure you specify the Compute-ResourcePool as the permission model in VMC is restrictive and you can not deploy directly to the vSphere Cluster and/or ESXi host.

Lastly, as mentioned earlier, the script I have provided is merely an example demonstrating the use of the xVC-Clone operation using the vSphere API and consuming it through PowerCLI. Unlike the Move-VM cmdlet which supports xVC operation natively, the New-VM does not currently support xVC-Clone. If you would like to see this natively supported as part of PowerCLI's New-VM cmdlet, be sure to add a +1 to PowerCLI Feature Request here.

Quick Tip - NSX-T 2.1 upgrade gotcha, use NSX Manager IP Address vs Hostname

by // 1 Comment

NSX-T 2.1 was released right before the holiday break and one of the biggest enhancement is support for VMware's upcoming Pivotal Container Service (PKS) which you can read more about here. Right before I took some much needed time off with the family, I had attempted an upgrade of my existing NSX-T 2.0 environment and ran into an issue which turned out to be a known issue but apparently it is no where listed on the NSX-T 2.1 release notes.

I figure I would share the simple workaround as it drove me a bit insane trying to figure out what was going on. After successfully uploading the NSX-T 2.1 upgrade bundle and then starting the upgrade, which starts off by updating the Upgrade Coordinator component and shortly after, I am shown the following error message:

This page is only available on the NSX Manager where Upgrade Coordinator is running. To enable the service, run the command "set service install-upgrade enabled" on the NSX Manager. If the install-upgrade service is already enabled, try disabling it using "clear service install-upgrade enabled" and then enable it again.

Although the error seems to suggest the Upgrade Coordinator service may not be running (it was), even after performing the recommended operations, the error message continue to persists as seen in the screenshot below.


After reaching out to Engineering as I was out of ideas on how to further troubleshoot the issue, it turns out this was actually a known upgrade issue going from 2.0 to 2.1. Instead of connecting to the NSX-T Manager using its Hostname (FQDN), I needed to use the IP Address instead for the upgrade. Once I logged back in using the IP Address, I was no longer seeing the error message and could proceed with my NSX-T upgrade as shown in the screenshot below.

Bulk VM Migration using new Cross vCenter vMotion Utility Fling

by // 60 Comments

Over the last few years, I have spoken to a number of customers who have greatly benefited from the ability to live migrate Virtual Machines across different vCenter Servers that are NOT part of the same vCenter Single Sign-On (SSO) Domain, which I had first shared back in 2015 here and here. This extended capability of the Cross vCenter vMotion feature enabled customers to solve new use cases that were challenging, especially for scenarios such as Datacenter migration, consolidation or even migrating existing workloads from their current environment into new SDDC deployments such as VMware Cloud Foundation (VCF) as an example.

Although customers could initiate Cross vCenter vMotions using the vSphere API which included PowerCLI (Move-VM cmdlet was enhanced in 6.5, more details here), the overall experience was still not as friendly. This was especially true for customers who may only have a small number of VMs to migrate and prefer a UI-based interface rather than an API/CLI only option. In addition, for large number of VM migrations, there was not an easy way to perform "batch" VM migrations that was easily consumable for folks who may not have a strong background in Automation or the vSphere APIs.

Today, I am pleased to share a new VMware Fling called the Cross vCenter Migration Utility that will help simplify the consumption of initiating VM migration(s) across different vCenter Servers, especially between dispart SSO Domains where a graphical interface was not available. This solution was developed out of our VMware Cloud Foundation (VCF) Engineering group which is part of the Integrated Systems Business Unit at VMware. I had spoken to a number of folks within the group about the extended Cross vCenter vMotion capability and I was super excited when I heard they were planning to release this tool as a Fling and make it available to all customers. I was fortunately to have been involved in the project alongside the Engineering lead Vishal Gupta and we are excited that we can finally talk about this project and see how customers will be using this new tool.

UPDATE (05/07/18) - The Fling has just been updated to 2.0 with the following new features:

  • Added support to select individual host as the placement target
  • Added support for migrating VMs with shared datastore
  • Added clone functionality in addition to relocate
  • Added resource summary details for placement targets
  • Added a prompt to verify site thumbprint during SSL verification
  • Added a link to refresh vm list in the inventory view
  • Updated REST APIs to add operation type parameter

Cross vCenter Migration Utility Fling

Cross vCenter vMotion Requirements: KB 2106952

Download Fling here


Features

  • Completely UI-driven workflow for VM migration
  • Provides REST API for managing migration operations
  • Works with vCenter not part of the same SSO domain
  • Supports both live/cold migration of VMs
  • Batch migration of multiple VMs in parallel
  • Flexible network mappings b/w source and destination sites

[Read more...]