WilliamLam.com

Search Results for: content library

Nested ESXi 6.7 Virtual Appliance Updates

by // 34 Comments

I know many of you have been pinging me the last couple of days for an updated Nested ESXi 6.7 Virtual Appliance and I have just finished my strict quality control process 🙂 The only minor change with the 6.7 appliance is the VM is now configured with EFI Firmware, where as in the past it was set to BIOS. As of vSphere 6.5+ appliances, the customization scripts are automatically removed by default which means that customers can turn on Secure Boot feature post-deployment without having to perform any manual workarounds. In addition, you will find a few more updates related to the updated ESXi appliance below. I hope you enjoy these free resources to help learn and plan for your vSphere 6.7 upgrades, Happy Friday!

Note: These solutions are all developed during off hours and does take a considerable amount of time/effort to manage and update. Although they are provided to you as a free solution, the development itself is not 🙂

o

Nested ESXi 6.7 Appliance:

ESXi 6.7 Virtual Appliance (Nested_ESXi6.7_Appliance_Template_v1.ova)

Nested ESXi Content Library

If you are using my Nested ESXi Content Library, I have updated it to include the latest 6.7 Appliance. Simply refresh your Content Library to automatically pull down the image or you can create a new Content Library by subscribing to the following URL: https://download3.vmware.com/software/vmw-tools/lib.json For more details, please take a look at this blog post here.

vGhetto vSphere Automated Lab Deployment:

For those that use my vGhetto lab deployment script to automate a fully functional vSphere environment, I have created a new version of the script to support vSphere 6.7 which you can find more details here. One neat feature that was suggested by Christian Mohn awhile back was the ability to get more insights to what is happening during the VCSA deployment since the verbosity can be quite distracting on the primary screen. There is now a new $enableVerboseLoggingToNewShell variable that is enabled by default to spawn a new PowerShell console that will watch the VCSA installer logs, so you have a better idea of what is going on.

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.

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...]