WilliamLam.com

Why is there a "No access" vSphere Role?

by // 5 Comments

vSphere's (vCenter Server & ESXi) authorization system includes several pre-canned Roles such as Read-Only, Administrator and Virtual Machine Administrator as an example. One of the roles that has intrigued me for awhile which is the "No access" role. This seems to be a really odd role to have, I mean what would you do with such a role if it does not have access to anything?

In a conversation I had last week with a fellow colleague, the "No access" role made its way into the conversation and I learned that there was a specific use case for this role, however it was unclear what that might have been. This go me interested and I decided to reach out to some folks to see if I can get to the bottom of this and the use case associated with it.

It turns out there are some customers who have some very interesting requirements in which they need to separate out users who have the Administrator role and prevent them from seeing and performing operations on specific vSphere Inventory objects. An example of this would be a vCenter Server with 4 vSphere Clusters where Admin1 can only see the first two Clusters and Admin2 can only see the last two Clusters and both users have the Administrator role.

To accomplish the above example, you can leverage the "No access" role in the following manner. As the "Uber" Administrator, you would assign both Admin1 and Admin2, lets call them Alan and Cormac the Administrator role at the vCenter Server level. This will grant them full access to the entire vSphere Inventory.

Now, to prevent Alan from seeing Cluster 3 & 4, we need to go into the Cluster object and add the "No access" role to both those objects. We do the same for Cormac but for Cluster 1 & 2. If we now login as the user Alan, we will see that only Cluster 1 & 2 are visisble.

If we login with the user Cormac, we can only see Cluster 3 & 4 as expected.

Although this may not be a common request in your environment, I can see some interesting use cases for having such a setup like on-boarding a new junior admin and wanting to provide them Administrative access to particular Clusters and removing the views for others they should not have access to.

I would like to thanks Rupam from our GSS organization for sharing the reasoning behind "No access" as well as a specific use case for the feature.

How do I find my SSO Server 5.5 Site name?

by // 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.

How to properly clone a Nested ESXi VM?

by // 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]