WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Search Results for: vsphere MOB

How to automate vFRC configurations using the command-line in ESXi

11.20.2013 by William Lam // 1 Comment

While working on my vSphere Flash Read Cache (vFRC) articles last week, I wanted to be able to quickly build out my vSphere environment so that vFRC was fully configured as part of my ESXi installation using a Kickstart script. This would allow me to simply add my ESXi hosts into vCenter Server and not have to go through the vSphere Web Client for each host configuring vFRC. Now of course the vSphere Web Client is not the only option to configure vFRC, you can also use the vSphere APIs by creating your own script or even using the new vFRC PowerCLI cmdlets as an alternative.

However, I was interested in creating a very simple script that I could easily integrate with my kickstart deployment as that is what I am using for automated provisioning of my Nested ESXi hosts. With a bit of research and some trial/error, I have come up with a process that can be fully automated from the command-line of ESXi. In my environment I have a Nested ESXi host that contains three SSD's (4GB each) which will be used to construct my Virtual Flash Resource.

Note: Jump to the very bottom for a completely automated script to configure vFRC for your ESXi host.

Step 1 -You will want to list out the available SSD devices on your ESXi host, you can do so by using the following ESXCLI command:

esxcli storage vflash device list

You will need to make a note of the device ID's as they will be required in the sub-sequent steps.

Step 2 - Next we will need to partition our devices before we can create VFFS (Virtual Flash File System) and we will need to calculate the end sector if we wish to consume the entire device. To do so, we will need to use the partedUtil command and specify the "getptbl" option to identify some information.

partedUtil getptbl /vmfs/devices/disks/naa.6000c2932c4ed8a540b6e9f0be9e1009

You will need to make a note of the first three numbers which represents number of cylinders, number of heads and number of sectors per track. To calculate the end sectors, the equation will be the following: (Number of Cylinders x Number of Heads x Number of Sectors Per Track) - 1

In our example we have (522*255*63)-1 which gives us 8385929

To create the partition, we will again use the partedUtil and specify "setptbl" option by running the following command (ensure to replace your end sector value):

partedUtil setptbl /vmfs/devices/disks/naa.6000c2932c4ed8a540b6e9f0be9e1009 "gpt" "1 2048 8385929 AA31E02A400F11DB9590000C2911D1B8 0"

For more details on using the partedUtil command, please refer here and here.

Since my other two devices are exactly the same size, I can just re-use the command and replace the device path. Ensure all devices that you wish to use in your Virtual Flash Resource is partition before moving onto the next step.

Step 3 - We will now create our VFFS volume which only needs to be created on one of the devices. In this example, I have chosen to use the first SSD device as shown in "esxcli storage vflash device list". To create the VFFS volume we will use the vmkfstools tool just like we would if we were creating a VMF volume but instead use the "vmfsl" type.

Run the following command to create your VFFS volume, you will need to append :1 to the end of the SSD device to specify the partition you created earlier as well as a display name of the volume which I chose vffs-$(hostname -s) which will use the short hostname of the ESXi host

vmkfstools -C vmfsl /vmfs/devices/disks/naa.6000c2932c4ed8a540b6e9f0be9e1009:1 -S vffs-$(hostname -s)

Step 4 - Once you have your VFFS volume created, you can extend it with additional SSD devices by using vmkfstools and specifying the -Z option. The syntax for the command is the SSD device partition you wish to add followed by the source SSD device containing the VFFS volume.

Here is an example of the command:

vmkfstools -Z /vmfs/devices/disks/naa.6000c29498be5c56231d631d9c6cbee8:1 /vmfs/devices/disks/naa.6000c2932c4ed8a540b6e9f0be9e1009:1

You will be prompted on whether you want to extend and to confirm enter value of 0.

You will need to do this for all SSD devices you partition earlier to be part of the same VFFS volume.

Step 5 - To confirm that everything was configured correctly, we will use vmkfstools to query our VFFS volume by running the following command and specifying the path to our VFFS volume:

vmkfstools -Ph /vmfs/volumes/vffs-vesxi55-10

From the output we should see the filesystem for the volume is of type VFFS and we should also see the three SSD devices that is backing this VFFS volume as shown in screenshot above.

Step 6 - Finally to make this new VFFS volume visible to the ESXi host, we will need to refresh the ESXi storage system and we can do so by running the following vim-cmd:

vim-cmd hostsvc/storage/refresh

At this point, we now have a fully configured VFFS volume. If you jump right into the vSphere Web Client expecting to see your new Virtual Flash Resource on your newly configured ESXi host, you might be in for a surprise! You will actually NOT see the VFFS volume that we just configured which stumped me initially.

It turns out simply creating a VFFS volume does not automatically equate to configuring a Virtual Flash Resource. You still need to configure the ESXi host to add the Virtual Flash Resource based on your VFFS volume and in my opinion that seems to be quite odd and counter-intuitive. Today there is no CLI command to add the Virtual Flash Resource, you would need to use either the vSphere Web Client or use the vFRC vSphere API. If you login to the vSphere Web Client and configure a Virtual Flash Resource, you will see the VFFS volume that we have created and you just need to select it and it will automatically add it.

This is not very ideal if you want to completely automate vFRC configurations and I decided to leverage my knowledge of the vFRC vSphere APIs and create a very simple python script that would call into the ESXi host's MOB and issue the HostConfigureVFlashResource() method. This was sort of a quick/dirty way to call the vSphere API and add in the Virtual Flash Resource.

Disclaimer: These scripts are provided as examples, please test these scripts in your development/test environment before running them in production.

To make this really useful I have created two scripts that can be embedded into either a kickstart script or executed manually. The script will automatically perform the above operations above as well as configure the Virtual Flash Resource without any user input/intervention.

The main script is called configurevFRC.sh which is a shell script that performs the majority of the work and it then it calls the python script which is called addVirtualFlashResource.py (ensure you change the password variable in the script) for adding the Virtual Flash Resource. You need to download both scripts and run them on the ESXi Shell.

Here is the contents of configurevFRC.sh (you can download both scripts using the links above):
Here is a sample execution of configurevFRC.sh script:

In the future I hope we can completely automate vFRC configurations from the command-line as we can using the vSphere Web Client or vSphere APIs. For now, this solution will help get you around the limitations we have in the command-line utilities.

HostConfigureVFlashResource

Categories // Uncategorized Tags // ESXi 5.5, vFRC, vmfsl, vmkfstools, vSphere 5.5, vSphere Flash Read Cache

Dude, Where's My vCenter Server 5.1 Components Installed At?

04.03.2013 by William Lam // 5 Comments

You would be surprised at the number of times I have heard this question get asked and this is not regarding the installation path but the specific server a given vCenter Server 5.1 component is installed on. I am just wondering if people are somehow miss-placing their infrastructure? I would hope that most organizations have some type of CMDB (Configuration Management Database) even if it is just a spreadsheet or at a minimum a memorable hostname. In any case, this question is only relevant for those of you who decided to separate out the vCenter SSO (Single Sign-On) Server, vSphere Web Client, Inventory Service and the vCenter Server and are now wondering where a given component is installed at.
To begin, you will need to know at a minimum where your vCenter Server is installed at. If you do not know that, then you should take the walk of shame and install this utility (be-careful with port scanning tools, as it may not be allowed by your Security Operations team). Go to the advanced settings of your vCenter Server and look up one of the following settings:
  • config.vpxd.sso.sts.uri
  • config.vpxd.sso.groupcheck.uri
  • config.vpxd.sso.admin.uri

All three of these settings should contain the same hostname or IP Address which is the location of where your SSO Server is installed. You can also find this information by looking at the vCenter Server configuration file located in the following location:

Windows vCenter Server: C:\ProgramData\VMware\VMware VirtualCenter\vpxd.cfg
vCenter Server Appliance: /etc/vmware-vpx/vpxd.cfg

Next, you will need to login directly to your vCenter Server (RDP or SSH) depending on the version you are using. Using the hostname or IP Address of our vCenter SSO Server, we will now connect to the Lookup Service which is installed alongside the vCenter SSO Server. This service will provide us with the location of all services registered to vCenter SSO and we will be able to identify the location of the remainder vCenter Server components.

For Windows vCenter Server, make sure you have the JAVA_HOME environmental variable set to C:\Program Files\VMware\Infrastructure\jre and open up a command prompt and run the following (subsitute in the hostname or IP Address of your vCenter SSO Server):

vSphere 5.5

"C:\Program Files\VMware\Infrastructure\VMware\CIS\vmware-sso\ssolscli.cmd" listServices https://winvc.primp-industries.com:7444/lookupservice/sdk

vSphere 5.1

"C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli\ssolscli.cmd" listServices https://winvc.primp-industries.com:7444/lookupservice/sdk

We can take a look at the serviceName which describes the specific vCenter Server component such as the vSphere Web Client or Log Browser and endpoints property will tell you which server it is installed on.

For vCenter Server Appliance, there is a similar command by running the following:

/usr/lib/vmware-sso/bin/vi_regtool listServices https://172.30.0.186:7444/lookupservice/sdk

The only vCenter Server component that we have not found is the Inventory Service. To find the server where this component is installed, we just need to look at the vCenter Server Extensions and and we can simply open up a web browser and connect to the following URL (substitute in your vCenter Server address):

https://vcsa.primp-industries.com/mob/?moid=ExtensionManager&doPath=extensionList[%22com.vmware.vim.inventoryservice%22].healthInfo

Hopefully at this point you are able to figure out where all your vCenter Server 5.1 components are installed at and you are also documenting all this information in your CMDB or spreadsheet 🙂

Categories // Automation Tags // inventory service, lookupservice, sso, VCSA, vcva, vSphere 5.1, vSphere 5.5, vsphere web client

Cool Undocumented Features in vCloud Director 1.5

09.06.2011 by William Lam // 6 Comments

While working on the updated script in Automating vCloud Director 1.5 & Oracle DB Installation, I did some digging in my lab deployment and noticed a few interesting things about the new vCloud Director 1.5 installation.

The first thing I noticed after configuring a new Provider vDC and the vCloud Agent (stored in /opt/vmware/vcloud-director/agent) is pushed out to the ESXi 5 hosts, a new esxcli module is added for vCloud Director under /usr/lib/vmware/esxcli-vcloud

There are 6 namespaces that ranges from simple configuration query, network fence management, account manage and also something called "esxvm" which I'll go into a little bit later. I am not sure why this is not in the vCloud Director documentation, I was not able to find any reference to the new esxcli operations. You may also notice the use of legacy "vslauser" (Virtual Software Lifecycle Automation) throughout vCloud Director, even though it was re-written from the ground up, it looks like VMware decided to either keep the name or some of the code related to the service account.

Here is an example of running "esxcli vcloud about get" command:

Here is an example of running "esxcli vcloud fence getfenceinfo" command:

Lastly, here is an example of what "esxvm" namespace provides:

As you can see above, there are two operations: disable/enable support for 64-bit nested virtual machines. This is exactly the same configuration as I blogged about in How to Enable Support for Nested 64bit & Hyper-V VMs in vSphere 5 but using esxcli interface with vCloud Director 1.5. Let's take a look at what happens when we run the "enable64bitnested" operation.

No surprise, we see that it automatically appends the required vhv.allow = "TRUE" flag which enables the support of running nested 64-bit virtual machines within a physical ESXi 5 host.

You might be asking, why is this in vCloud Director? Well if you attended VMworld 2011 or previous VMworlds and took part in the hands on labs, you will know that VMware utilizes vPods or nested ESXi to deploy their labs. I suspect, this functionality was added into vCloud Director so that VMware can easily leverage nested ESXi for hands on labs or vSel deployments just like they did with Lab Manager previously.

While look into this, I recall a very interesting article by Jason Boche - Deploy ESX & ESXi With Hidden Lab Manager 4 Switch in which Jason identifies a hidden flag in the Lab Manager database that enables a special feature in deploying nested ESX(i) VMs including customization through the use of a special version of VMware Tools for ESX(i). I was curious to see if something similar existed in the new vCloud Director that provided similar functionality.

Looking at the SQL install scripts located in /opt/vmware/vcloud-director/db/{oracle/mssql}, I noticed an interesting config called "extension.esxvm.enabled" in NewInstall_Data.sql file

As you can see from the insert statement, by default this value is set to "false" and we can also confirm this after vCloud Director has been installed and configured by querying the database. Let's go ahead and update this value to "true" and let's see what happens. 

Once you have verified the value has been successfully updated, I decide to use the same trick that Jason had identified with the special "Uber Admin Screen" to load the changes. To my surprise, the trick still worked but the page was not super Uber .... To enable the screen, you will need to click on the "About" page and then click CTRL+U (ctr + shift + u), which will toggle the "Uber Admin Screen".

The available options are quite limited as you can see but there are some new hidden options such as a new debug and console toggle. When you enable these options, you will see them at the bottom right of your screen including a counter of the amount of memory being used for your vCloud Director deployment.

After toggling the hidden database feature, I was not able to see any additional pages relating to nested ESXi hosts, even after restarting vCloud Director. Through some testing, I found that the "extension.esxvm.enabled" actually controlled whether or not nested 64bit VM was enabled when the vCloud Agent was pushed out to ESXi 5 hosts. Instead of manually adding vhv.allow = "TRUE" or using esxcli vcloud esxvm enable64bitnested, vCloud Director will automatically configure the ESXi hosts for you. I still suspect there is probably a hidden interface in managing vESXi hosts and leveraging a specialized version of VMware Tools to automate the deployment of nested ESXi, but I have not found out yet.

UPDATE: Take a look at this blog post for the full details on building your own vSEL - The Missing Piece In Creating Your Own Ghetto vSEL Cloud

Categories // Uncategorized Tags // esxcli, ESXi 5.0, vcd, vcloud director, vSphere 5.0

  • « Previous Page
  • 1
  • …
  • 33
  • 34
  • 35
  • 36
  • 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

  • Ultimate Lab Resource for VCF 9.0 06/25/2025
  • VMware Cloud Foundation (VCF) on ASUS NUC 15 Pro (Cyber Canyon) 06/25/2025
  • VMware Cloud Foundation (VCF) on Minisforum MS-A2 06/25/2025
  • VCF 9.0 Offline Depot using Synology 06/25/2025
  • Deploying VCF 9.0 on a single ESXi host? 06/24/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