WilliamLam.com

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

How do I find my SSO Server 5.5 Site name?

12.10.2013 by William Lam // 11 Comments

During an SSO (Single-Sign On) Server 5.5 installation, you may have noticed a new input parameter called Site Name that you must now specify. This new Site name is meant to help users identify a specific SSO Server when more than one exists in an environment and used mainly for groupings today.

Note: Something to be aware of is that the Site Name can not be changed after installation which is a bit unfortunate, so choose carefully.

When adding an additional Windows-based SSO Server to an existing environment, a drop down list will automatically be populated with all the Site names. This is great if the Site name you selected makes sense (ideally it would) but in case you did not choose a specific name or forgot the relationship between the Site name and the SSO Server, then this can potentially post a challenge.

In my lab I have been recently doing some "SSO" testing and I needed to figure out the Site name for one a vCenter Server running on Windows as well as for a VCSA (vCenter Server Appliance). With a bit of digging and testing, here is how you can find the Site name for a given SSO Server.

Note: Since the VCSA is a pre-built Virtual Appliance, the Site name has already been configured to to always be "local".

Method 1 - You can leverage an SSO CLI utility found both in a Windows vCenter Server as well as the VCSA to query for this information.

Windows vCenter Server Utility: C:\Program Files\VMware\Infrastructure\VMware\CIS\vmware-sso\ssolscli.cmd

VCSA Utility: /usr/lib/vmware-sso/bin/vi_regtool

Both commands function exactly the same but do have different paths/name. The operation that we will be using is the "listServices" and we will also need to specify the Lookup Service URL which will be in the form of https://[SSO-SERVER]:7444/lookupservice/sdk

Here is an example of using the ssolscli.cmd in vCenter Server for Windows:

In the output you should see a list of services registered and you will also be able to find the Site name in either the serviceId property which includes the Site name in the pre-fix. In the screenshot above, the Site name is "Santa Barbara". You can also find the Site name by looking at viSite property for each service and based on the URL, you will see the IP Address/Hostname in which the Site name is associated with.

Method 2 - You can also find the Site name for a given SSO Server by logging into the vSphere Web Client and under the advanced vCenter Server settings, you can filter on config.vpxd.sso string and look for the serviceId property which will include the Site name. You can also find this same information by looking at the vCenter Server configuration file (vpxd.conf) but if you have access to the vSphere Web Client, it is a much quicker way as seen in the screenshot below.

Categories // VCSA, vSphere Tags // sso, ssocli, ssolscli, VCSA, vcva, vi_regtool, vSphere 5.5

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

  • « 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

  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • 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

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