WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud
  • Tanzu
    • Application Modernization
    • Tanzu services
    • Tanzu Community Edition
    • Tanzu Kubernetes Grid
    • vSphere with Tanzu
  • Home Lab
  • Nested Virtualization
  • Apple

How to Disable a vmnic in ESX(i)

06.24.2011 by William Lam // 8 Comments

There was another interesting thread today on the VMTN community forums about disabling an unused vmnic from an ESXi host due to false alarms being generated from HP SIM. Due to the specific hardware version, disabling the vmnic through the BIOS was not an option and there were no alternatives from the discussion.

I decided to dig a bit to see what I could find and stumbled upon a neat little utility called vmkchdev (VMkernel Change Device?) and from what I can tell provides a method passing a particular device to be controlled by either the VMkernel or as a passthrough device to a virtual machine (think VMDirect Path).

Disclaimer: Please note, this is using an undocumented utility. You should test this out in a development/lab environment before using and you may want to also contact VMware support to get their blessings***

~ # vmkchdev
Usage:
-s (scan device)
-v (give device to vmkernel)
-p (give device to passthru/VM)
-l (list device state)
-L (list device state with details)
[0x][seg:[bus[:slot[.func]]]]

What I found while testing the utility is by passing it over as a passthrough device, the vmnic is actually unrepresented to the VMkernel and does not show up under network adapters or even the unused/unlinked adapter list in the vSwitch configurations. It seems that it is just masks the device away from the VMkernel as you can still see the active configuration in esx.conf and you can see the device listed using vmkchdev.

Here is an example of an unused physical nic vmnic1 that we would like to disable and unpresent to an ESXi host.

Here is the output from esxcfg-nics:

First we need to identify the vmnic's PCI slot, we do by running the "-l" or list operation and searching for the particular vmnice device.

~ # vmkchdev -l | grep vmnic1
000:002:01.0 8086:100f 15ad:0750 vmkernel vmnic1

Next we will pass the device from the VMkernel to passthrough/VM using the "-p" flag and specifying the PCI slot, which in this case it is 000:002:01.0. We will also need to refresh the network section so the changes are reflected in the vSphere Client by using vim-cmd.

~ # vmkchdev -p 000:002:01.0
~ # vim-cmd hostsvc/net/refresh

If we list our vmnic again using vmkchdev, you will notice the device is now owned by passthru versus the VMkernel.

~ # vmkchdev -l | grep vmnic1
000:002:01.0 8086:100f 15ad:0750 passthru vmnic1

Now if we check the output of esxcfg-nics and the vSphere Client, you will notice that vmnic1 is no where to be found

If you would like to enable or re-present the disabled vmnic, you just need to pass the device back over to VMkernel by using the "-v" flag.

~ # vmkchdev -v 000:002:01.0
~ # vim-cmd hostsvc/net/refresh

Your vmnic should now re-appear on all your screens and any existing NIC teams that may have exists is automatically restored. This trick actually works on both a used and unused vmnic

If you are trying to do this on ESX, vmkchdev actually has an additional option called "console" for the Service Console.

[[email protected] ~]# vmkchdev
Usage:
-s (scan device)
-c (give device to console)
-v (give device to vmkernel)
-p (give device to passthru/VM)
-l (list device state)
-L (list device state with details)
[0x][seg:[bus[:slot[.func]]]]

I found that you need to pass the vmnic from VMkernel to Console, passing it to passthru/VM will not work and an error is thrown if you do. Again, you can easily re-enable by passing it back to the VMkernel

vmkchdev -c 000:002:01.0

If you would like to automatically persist this change across reboots, specifically for ESXi as changes are not saved. You will need to add the following lines to /etc/rc.local which will execute the disabling of the vmnic's after bootup.

/sbin/vmkchdev -p 000:002:01.0
vim-cmd hostsvc/net/refresh

You will also need to run /sbin/auto-backup.sh to ensure the changes to /etc/rc.local are saved and reloaded upon the next reboot. For ESX, you can place it in /etc/rc.local without having to do anything extra as the changes persists across reboots for classic ESX

Now you can play hide and seek with your vmnic's without resorting to a system reboot or touching the BIOS. Though ideally, if you do have unused devices, you should definitely disable them in the BIOS if you have the option. On a side note, this might be a fun trick to play on one of your co-workers by hiding all vmnics 😉

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Categories // ESXi, Not Supported Tags // esx4, esxi4.1, vmkchdev, vSphere 4.1

Semi-Interactive automated ESXi installation

05.09.2011 by William Lam // 18 Comments

There was a recent thread in the VMTN community forums where a user wanted to provide user input prior to an automated ESXi installation. This may sound odd at first, especially when we are talking about an unattended installation, the last thing you want is any type of user interaction. The reason for this requirement was to maintain a generic kickstart configuration file and based on the site specific input (IP Address, Netmask, Gateway, Hostname and DNS Servers), the ESXi installation would be able to deploy and configure itself the same across multiple locations.

UPDATE (01/10/19) - For ESXi 6.5 or greater, please take a look at this blog post for an updated solution

UPDATE (10/28/15) - Please take a look at this blog post on how to prompt for user input during an interactive or scripted installation of ESXi.

The other reason for this requirement is that all hosts in the user's environment must be configured with a static IP Address, this is not an uncommon requirement for many production environments to not have DHCP enabled networks. I can only assume the initial network the host is being built is either a private build network or booting off of local media such as a USB or CD-ROM device.

Whether you are booting off of local media or via PXE over the network, you have the ability to specify some boot parameters which includes things like IP Address, Netmask, Gateway and DNS Servers. These "bootstrap" options are fully supported and documented in the ESXi Installation Section. You can also specify advanced VMkernel boot parameters which may not be officially supported by VMware, but you can take a look here for more details.The concept of specifying these boot parameters is nothing new and has been supported since the early days of classic ESX and other popular UNIX/Linux distros for PXE boot/installations.

When you boot the ESXi installer, you may have seen a screen similar to the following in which you have a few seconds to hit the "tab" key to edit the boot options.

Once you hit the "tab" key, you will be able to see what the default boot options are and if you are PXE booting, you will also see some IP information appended towards the end of the string. This is where you can append or update additional parameters and later read in by your kickstart script.

Here is an example of an ESXi installation being PXE booted over the network and I have added 4 supported boot parameters and 2 custom ones.

If you take a look at the screenshot, the "+++" IP information towards the end is what was given by the DHCP server but I am interested in specifying a different IP Address for the ESXi installer to boot from. I provided new entries for ip, netmask, gateway and nameserver. You can also see that I introduced two new variables called hostname and dc, these will be used to specify the hostname of the ESXi host and also the name of the datacenter which will be used later in the kickstart script to rename a datastore.

Note: If you redefine the IP information, you do not need to change the IP information found after the "+++", these will just be over-written with the new IP information.

When specifying these boot parameters, you need to make sure it is after the "vmkboot.gz" but before "--- vmkernel.gz". To help make this clear, I have colorized the section that was appended to the default options.

vmkboot.gz dc=ghettoDC hostname=vesxi41-2.primp-industries.com ip=172.30.0.200 netmask=255.255.255.0 gateway=172.30.0.1 nameserver=172.30.0.100 ks=http://172.30.0.108/esxi41u1/ks.cfg --- vmkernel.gz --- sys.vgz --- cim.vgz --- ienviron.vgz --- install.vgz

Note: You can create any custom variables, the key in using the custom variables will be parsing from the boot command line using vsish which will be defined in your kickstart script. This will work also work for local media, but you MUST use a kickstart to perform the actual installation or inject the kickstart script into a custom ISO.

After you have provided all the input, you will then boot the installer and the the following kickstart configuration file is used to parse the boot options using vsish.

accepteula
autopart --firstdisk --overwritevmfs
rootpw vmware
install url http://172.30.0.108/esxi41u1
reboot

%include /tmp/networkconfig

%pre --unsupported --interpreter=busybox

CMDLINE_FILE=/tmp/cmdline
ESXI_INSTALL_LOG=/var/log/esxi_install.log

# extract boot options
vsish -e get /system/bootCmdLine > ${CMDLINE_FILE}

# extract and set variables
HOSTNAME=$(cat ${CMDLINE_FILE} | grep hostname | sed -e 's/.*hostname=\([^ ]*\).*/\1/')
IPADDR=$(cat ${CMDLINE_FILE} | grep ip | sed -e 's/.*ip=\([^ ]*\).*/\1/')
NETMASK=$(cat ${CMDLINE_FILE} | grep netmask | sed -e 's/.*netmask=\([^ ]*\).*/\1/')
GATEWAY=$(cat ${CMDLINE_FILE} | grep gateway | sed -e 's/.*gateway=\([^ ]*\).*/\1/')
NAMESERVER=$(cat ${CMDLINE_FILE} | grep nameserver | sed -e 's/.*nameserver=\([^ ]*\).*/\1/')
DC=$(cat ${CMDLINE_FILE} | grep dc | sed -e 's/.*dc=\([^ ]*\).*/\1/')

# create networkline based on boot options
echo "network --bootproto=static --hostname=${HOSTNAME} --ip=${IPADDR} --netmask=${NETMASK} --gateway=${GATEWAY} --nameserver=${NAMESERVER} --addvmportgroup=0" > /tmp/networkconfig

# persist custom variables in ESXi install log for %post section
echo "GHETTO_CUSTOM_VARIABLE-DC ${DC}" >> ${ESXI_INSTALL_LOG}

%firstboot --unsupported --interpreter=busybox --level=9999

#extract custom variables in ESXi install log
DC=$(grep "^GHETTO_CUSTOM_VARIABLE-DC" /var/log/esxi_install.log | awk '{print $2}')

vim-cmd hostsvc/datastore/rename datastore1 "${DC}-datastore1"

vim-cmd hostsvc/maintenance_mode_enter
vim-cmd hostsvc/enable_remote_tsm
vim-cmd hostsvc/start_remote_tsm
vim-cmd hostsvc/enable_local_tsm
vim-cmd hostsvc/start_local_tsm

The script does the following:

  1. Reads the boot options using vsish and temporarily stores the output to /tmp/cmdline for later use
  2. Extracts all the relevant boot parameters in /tmp/cmdline and stores them in variables to be used in the script.
  3. Creates the "network" stanza for static IP assignment of the ESXi host which includes: Hostname, IP Address, Netmask, Gateway and Nameserver
  4. Writing out the custom variable "dc" into /var/log/esxi_install.log because this will be persisted through the reboot and can be later read in for any %firstboot operations.
  5. Upon the reboot, %firstboot will execute and read from /var/log/esxi_install.log to extract the "dc" variable in which it will use to rename the local datastore

Note: The above is just an example of what you can do with custom parameters. You can easily add as many as you need for site specific configurations and then use those input in your post configure your ESXi host. Also note that you do not need to make sure of ip,netmask,gateway,dns parameters to use custom variables, these are all optional.

You can add as many custom entries as you would like, but this can easily get error prone due to the amount of typing required. One thing you can do to minimize the amount of typos is to pre-specify the custom variables in your PXE/TFTP configuration file.

To do so, your PXE/TFTP configuration file would look something like this:

IMEOUT 300 #30 seconds
PROMPT 1
DEFAULT menu.c32
SAY -
SAY vga - Install esxi410u1 (vga console)
SAY -

LABEL www.virtuallyghetto.com - Semi-Interactive ESXi Install
KERNEL mboot.c32
APPEND vmkboot.gz dc= hostname= ip= netmask= gateway= nameserver= ks=http://172.30.0.108/esxi41u1/ks.cfg --- vmkernel.gz --- sys.vgz --- cim.vgz --- ienviron.vgz --- install.vgz
IPAPPEND 1

This not only reduces the amount of typing but also lets the user know what variables must be defined in order for the installation to proceed.

I totally understand where the user is coming from and I have had this requirement in the past but I think having a static DHCP entry and maintaining a simple configuration file can easily solve this problem. This not only makes the deployment process hands-off as it should be in the first place but also removing the human factor out of the equation. Can you imagine deploying 100-300 ESXi hosts in a day? I sure can not if I had to manually type out all those addresses by hand.

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Categories // Automation, ESXi Tags // esxi4.1, kickstart, ks.cfg

How to add a splash of color to ESXi DCUI Welcome Screen

09.09.2010 by William Lam // 24 Comments

Earlier this year I created a simple vSphere SDK for Perl script that allows you to update ESXi's DCUI (Direct Console User Interface) banner with multiple lines of text. I originally thought you could not customize the text color or the background color, though recently I found out that was not the case. While doing some testing on ESXi 4.1, I noticed two files (support,welcome) located under /etc/vmware and looking at the contents of support, it made realize we might be able to change the colors.

Here is the contents of /etc/vmware/support, notice the special formatting of the variables including color tags:

I decided to use one of my favorite UNIX utility, "strings" to take at the dcui binary that is located under /sbin in the Busybox Console (Tech Support Mode) and discovered you can control both the font color and background color. There are also special variables that can be used to display information about the ESXi host such as the product version or IP Address.

Here are the supported colors:

white
black
dark-grey
light-grey
yellow

Here are the special variables:

assettag
BIOSversion
BMCversion
CIM_Chassis
CPLDversion
esxproduct
esxversion
hostname
ip
license
memory
OMC_MCFirmwareIdentity
OMC_SMASHFirmwareIdentity
OtherIdentifyingInfo
PLSAversion
serial-number
servicetag
ssl-thumbprint
supportperiod
supportstart
VersionString
VMware_HHRCSoftwareIdentity

There are two ways of updating the DCUI welcome banner: using local or remote esxcfg-advcfg or manually editing /etc/vmware/welcome file.

Here is an example of using vCLI's esxcfg-advcfg:

Here is what that looks like on the DCUI:

As you can see, this is not easy if you want to update multiple lines. You would need to add a lot more spaces to force newlines, but this becomes tedious and pretty much unreadable. The second method is edit the welcome file that is located in the Busybox Console, which requires you to enable ESXi's Tech Support Mode. I wrote a quick Perl script called generateDCUIScreen.pl which accepts an input file and allows a user to customize the output and the script generates the "welcome" file which is uploaded to your ESXi host.

Here is an example of the input file:

The script will parse the input file which will contain definitions for:

  • bgcolor and color as described above
  • special variables as described above (must use braces for variables to be translated)
  • custom text
  • "=space=" string which is unique to my script which generates the newlines

The script requires that you have Perl, but you do not need to have vSphere SDK for Perl. For ease of use, I executed the script using vMA.

Here is an example execution using the input file from above:


You will need to scp the new"welcome" file to your ESXi host under /etc/vmware which is empty by default. For the changes to take effect, you will need to run the following command at the console:

kill $(ps | grep dcui | awk '{print $1}')

This will kill dcui utility and watchdog process will spawn a new instance causing the change to take effect Note: A reboot will also do the job, but be sure to run /sbin/auto-backup.sh before doing so, that way the change will be backed up.

Here is what DCUI screen looks like:

As you can see, you can control variety of pre-defined variables including hostname and IP Address and custom text for your organization. This is useful for those that do not want to expose all the information that available on the default DCUI screen, which may be a security concern for some organizations. A few things to note, I was not able to fill the entire screen like the default DCUI banner and the "welcome" file is character sensitive and you need to use tabs or white spaces to force the background to get filled. There is also a limit in the number of characters per row before it wraps to the next line.

I am sure there is someone out there that will create some interesting ASCII art, but here is my 5min free hand attempt at it 😉

This can easily be integrated into a scripted install using the new ESXi 4.1 kickstart feature.

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Categories // ESXi, Not Supported Tags // dcui, esxi4, vSphere 4.1

  • « Previous Page
  • 1
  • …
  • 102
  • 103
  • 104

Search

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Infrastructure Business Group (CIBG) at VMware. He focuses on Cloud Native technologies, Automation, Integration and Operation for the VMware Cloud based Software Defined Datacenters (SDDC)

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

Connect

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Support

Recent

  • ESXi running in unexpected places ... 05/20/2022
  • Quick Tip - Adding a vTPM (Virtual Trusted Platform Module) to a Nested ESXi VM 05/13/2022
  • vSphere Event-Driven Automation using VMware Event Router on VMware Cloud on AWS with Knative or AWS EventBridge 05/10/2022
  • Integrating VMware Event Broker Appliance (VEBA) with Zapier 04/28/2022
  • Using Terraform to activate Tanzu Kubernetes Grid Service on VMware Cloud on AWS 04/27/2022

Advertisment

Copyright WilliamLam.com © 2022