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.

Deploying NSX-T VIBs and/or creating custom NSX-T Image Profile

by // Leave a Comment

Similiar to its earlier predecessor, NSX-T also provides complete lifecycle management (LCM) of its underlying NSX components (Controllers, Edges and Managers) including the Fabric Nodes (e.g. ESXi and/or KVM hosts). Additionally, a new Upgrade Coordinator is now part of NSX-T which greatly simplifies the patching and updating of the network virtualization platform. However, for existing vSphere customers who already have a process for distributing VMware VIBs using vSphere Update Manager (VUM) and/or custom Image Profiles, being able to leverage their existing methods is quite important. This is especially true for customers or system integrators who wish to slipstream all necessary VIBs as part of their base ESXi image for initial deployment which may come in the form of an automated installation via Kickstart and/or even manual install using an ISO image.

The good news is that like NSX-V, NSX-T also supports the same set of deployment methods that customers are already familiar with. I had recently looked into this due to a few questions that I and a few other folks had during our NSX-T Bootcamp training a couple of weeks back. I also did not see anything in the existing NSX-T documentation and figure it would be useful to outline the specific steps for each of the installation methods, especially when creating a custom ESXi Image Profile using PowerCLI which requires a particular order.

Note: Auto Deploy is currently not supported with NSX-T.

[Read more...]

Translating vSAN VM Object IDs (UUID to VM and VM to UUID)

by // 2 Comments

I was working on one of my vSAN Clusters a few weeks back and I had noticed a bunch of vSAN Objects being listed under the "Other" category within the vSAN Virtual Objects Health view as shown in the screenshot below.


I could not figure out what files or VMs these vSAN objects were actually associated to and it was especially strange since all VMs that were deployed on my vSAN Cluster were already properly showing up under this view and I could not account for these "Other" vSAN Objects. I had reached out to a few folks to see if anyone knew how to identify these objects and the only suggestion I had received back was try to run this python vSAN Health Status script located on one of the ESXi hosts participating in the vSAN Cluster to see if it provided what I needed.

The script is located at /usr/lib/vmware/vsan/bin/vsan-health-status.pyc and you run it like the following:

python /usr/lib/vmware/vsan/bin/vsan-health-status.pyc > /tmp/output

The above command just runs the script and stores its output (which is quite extensive) to /tmp/output. Once the script finishes, you can then open up the file using vi and search for the specific vSAN Object UUID in question. I was able to eventually identify what these vSAN Object UUIDs were mapped to (more on this later), but the overall experience was not ideal and it required SSH access to ESXi host which most customers disable by default. In addition, the process was pretty manual and tedious if you wanted to check multiple vSAN Object UUIDs.

So what did I do, well I looked for a better way of course! It turns out the output produced by vsan-health-status.pyc is actually all available using the vSAN Management API. Not only can you obtain this information programmatically and remotely but you can also retrieve this information by simply going to vCenter Server rather than having to directly connect to an ESXI host which was huge negative for me regarding the previous solution.

[Read more...]