WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

How to properly clone a Nested ESXi VM?

12.06.2013 by William Lam // 53 Comments

I often hear from users that they would like to be able to just clone from an existing Nested ESXi VM that has already been configured and just create additional Nested ESXi VM instances from that. For me personally, I do not have a use case for this since I just deploy additional ESXi instances using an automated Kickstart deployment. However, I can see why this would be useful for anyone that does not have an automated deployment or just want to quickly deploy additional Nested ESXi instances by just cloning from an existing image and then manually change the networking configuration afterwards.

UPDATE (07/01/21) - As of ESXi 7.0 Update 2, cloning an ESXi boot volume (Nested or Physical) is no longer safe and can lead to data corruption. Please refer to the following two VMware KB articles for more information on this topic https://kb.vmware.com/kb/84280 and https://kb.vmware.com/kb/84349 

First off, cloning of a Nested ESXi VM is possible and you can already do this today. You will get a brand new Virtual Machine that will have a unique MoRef ID, InstanceUUID, BIOS UUID and MAC Addresses for each of the virtual network adapters which you can see an example of this from the screenshot below.

Everything from outside of the guest OS looks great as we would expect but there is actually two issues from within ESXi that you may not be aware of.

  • The first issue is that you will get a duplicated MAC Address of the VMkernel interface(s) because the Nested ESXi configuration is exactly the same.
  • The second issue is having a duplicated ESXi System UUID, also known as a VMkernel UUID which should normally be unique and can sometimes be used for tracking purposes. You can see this System UUID by running the following ESXCLI command: esxcli system uuid get or by looking in esx.conf configuration file.

To properly clone an existing Nested ESXi VM, you will need to perform the following two operations within the Nested ESXi VM prior to cloning.

First Configuration - There is an advanced ESXi setting called FollowHardwareMac that will automatically update the VMkernel's MAC Address whenever the Virtual Machine's virtual network adapter MAC Addresses changes. To do so, you will need to run the following ESXCLI command:

esxcli system settings advanced set -o /Net/FollowHardwareMac -i 1

Second Configuration - The other modification that is required is to delete the existing System UUID entry in /etc/vmware/esx.conf configuration file. This will ensure a new System UUID will automatically be generated when the system boots up. To do so, open esx.conf and delete the entire /system/uuid line entry as seen in the screenshot below. Here is a quick snippet you can run without needing to open up VI:

sed -i 's#/system/uuid.*##' /etc/vmware/esx.conf

To ensure the file is persisted, run /sbin/auto-backup.sh

Once both configurations have been performed you are now ready to start cloning additional Nested ESXi instances. You will still need to login to each Nested ESXi VM and manually change the IP Address and hostname which you of course can leverage the Guest Operations API if you have VMware Tools for Nested ESXi installed.

If you plan on joining your "cloned" Nested ESXi instances to a vCenter Server and the ESXi hosts contains a local datastore, you will not be able to add the hosts to the same Datacenter/Cluster. The reason for this is that the cloned ESXi hosts will have a duplicated VMFS UUID. To fix this, you just need to re-signature the VMFS volume by using the following ESXCLI command:

esxcli storage vmfs snapshot resignature -l [VMFS-VOLUME]

Categories // ESXi, Nested Virtualization Tags // clone, ESXi, nested, nested virtualization, uuid

Deploy a truly dynamic OVF using Deployment Option based on the 4 Computes (CPU, Memory, Storage & Network)

12.04.2013 by William Lam // 4 Comments

After learning about the Dynamic Disks feature in OVF, I decided to revisit OVF Deployment Options again and investigate whether it was possible to include all four computes (CPU, Memory, Storage and Network) as part of the deployment option. What would be really nice is to have a flexible deployment option which allows a user to select a specific "size" or "configuration" based on their environment and the appropriate recommended compute (CPU, Memory, Storage and Network) will automatically be selected as part of the Virtual Appliance deployment.

Below is an example of what the three "Sizes" (Small, Medium and Big) could look like:

We could have easily changed "Size" to "Deployment Type" (Dev, Test, Prod) or any other definition for that matter since as this is just a string text and configuration mapping. To demonstrate the above configuration using OVF Deployment Options I have created a sample OVF called Dynamic-vGhetto-vApp.ovf that can be downloaded here.

To use the Dynamic-vGhetto-vApp.ovf example OVF, you will need to have access to a vCenter Server since the OVF Deployment Options feature is only available there. As part of the OVF deployment wizard, you should now see a new section for Deployment Options providing a drop down menu for a Small, Medium or Large deployment and can include a description for each configuration as seen in the screenshot below.

For the CPU/Memory section it is pretty straight forward on how it works and you can get more details by taking a look at this blog article here. For the Storage section we are leveraging the recetnly discovered feature of Dynamic Disks and you can refer to this article here for further details. The last compute that we have not taken a look at before is the Network section which will allows a user to assign a certain number of virtual network adapters based on the selected deployment option.

There are two parts to the Networking section, the first is the OVF network labels which are defined in the NetworkSection of the OVF descriptor as seen in the example below:

    <Network ovf:name="ManagementNetwork1">
      <Description>Management Network 1</Description>
    </Network>
    <Network ovf:name="DataNetwork">
      <Description>Data Network</Description>
    </Network>
    <Network ovf:name="ReplicationNetwork">
      <Description>Replication Network</Description>
    </Network>
    <Network ovf:name="ManagementNetwork2">
      <Description>Management Network 2</Description>
    </Network>

Each OVF network label is defined using the ovf:name property and that is then mapped to the appropriate virtual network adapter Item. To control the number of virtual network adapters for each deployment option, you will use the ovf:configuration property and specify the deployment type that are applicable for each virtual network adapter.

      <Item ovf:configuration="small medium large">
        <rasd:AddressOnParent>7</rasd:AddressOnParent>
        <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
        <rasd:Connection>ManagementNetwork1</rasd:Connection>
        <rasd:Description>VmxNet3 ethernet adapter on "Management Network 1"</rasd:Description>
        <rasd:ElementName>Network adapter 1</rasd:ElementName>
        <rasd:InstanceID>12</rasd:InstanceID>
        <rasd:ResourceSubType>VmxNet3</rasd:ResourceSubType>
        <rasd:ResourceType>10</rasd:ResourceType>
        <vmw:Config ovf:required="false" vmw:key="wakeOnLanEnabled" vmw:value="true"/>
      </Item>

You can refer to Dynamic-vGhetto-vApp.ovf for a complete working example of the Networking section.

One thing to note for the Networking section when selecting your Deployment Option is that ALL virtual network adapters will be shown in the UI, but you only need to specify the destination portgroup mapping for the OVF labels that will be provisioned for your particular configuration. I know this can be a little bit confusing but you can ignore the others. To give you a concrete example, the "Small" configuration only deploys the VM with a single virtual network adapter which maps to the "ManagementNetwork1" OVF label and this is the only destination portgroup mapping you need to specify, you can ignore the rest.

Here is a screenshot of the Virtual Machine configurations using a "Small" deployment:

Here is a screenshot of the Virtual Machine configurations using a "Medium" deployment:

Here is a screenshot of the Virtual Machine configurations using a "Large" deployment:

I think this is probably by far the coolest feature of OVF and I really hope to see more Virtual Appliances leverage this feature including appliances built from VMware. I would like to give a big thanks to Anders Madsen for helping me put the final two pieces of the puzzle together for Deployment Options leveraging all four computes.

Categories // Uncategorized Tags // deployment options, DeploymentOptionSection, dynamic disks, ova, ovf

How to upgrade to the latest VSAN Beta Refresh of RVC on Windows?

12.03.2013 by William Lam // 4 Comments

A variety of new updates can be found in the latest VSAN Beta Refresh including a new RVC (Ruby vSphere Console) namespace called SPBM (Storage Policy Based Management) that allows users manage and configure VM Storage Policies. However, this update is currently only available for the VCSA (vCenter Server Appliance) and there is no update package for the Windows based vCenter Server (I hear this is being looked into).

UPDATE 12/04/13 - I just received an update from Cormac that we have just released a VSAN Beta Refresh for vCenter Server for Windows which you can download here.

For those of you who are running vCenter Server on Windows for the VSAN Beta and wish to try out the latest release of RVC which includes additional fixes as well as the new SPBM namespace can do so by just updating to the latest RVC package.

Step 1 - Download the rvc_1.3.3-1_x86_64.rpm package from the VSAN Beta website and upload that to your Windows vCenter Server.

Step 2 - Download and install 7zip on the Windows vCenter Server or another Windows server which can be used to extract the contents of the RPM package.

Step 3 - Right click on the RPM package and select the "Extract to rvc_1.3.3-1_x86_64/" option which should create a new folder that contains a new file called rvc_1.3.3-1_x86_64.cpio.

Step 4 - Right click on the CPIO package and select the "Extract to rvc_1.3.3-1_x86_64/" option which will create another folder containing the actual RVC bits.

Step 5 - Copy the contents from inside of opt\vmware\rvc to the following path on your vCenter Server C:\Program Files\VMware\Infrastructure\VirtualCenter Server\support\rvc Once you have replaced the updated RVC bits, you can now change into that directory and launch RVC by just typing "rvc" and hitting enter. To confirm that RVC has been successfully updated, you can then type "spbm." and hit tab and you should see eight new SPBM commands.

To learn more about RVC for Windows, I would highly recommend you check out Eric Bussink's blog article here.

Categories // VSAN, vSphere 5.5 Tags // ruby vsphere console, rvc, spbm, Storage Policy Based Management, vm storage policy, VSAN, vSphere 5.5

  • « Previous Page
  • 1
  • …
  • 424
  • 425
  • 426
  • 427
  • 428
  • …
  • 560
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025