virtuallyGhetto

vsish

Quick Tip – Using ESXi to send Wake-on-Lan (WoL) packet

by 1 Comment

The ability to power on a system over the network using Wake-on-Lan (WoL) can be extremely useful, especially if you are not physically near the system or after a power outage. I personally have been using the wakeonlan utility on my macOS system for several years now.

The syntax is super easy, you just provide the MAC Address of your system:

wakeonlan 54:b2:03:9e:70:fc
Sending magic packet to 255.255.255.255:9 with 54:b2:03:9e:70:fc

I recently came to learn that ESXi itself has the ability to send a WoL packet from the ESXi Shell! This could be handy without having to install WoL client, especially if you have access to an ESXi host.

vsish -e set /net/tcpip/instances/defaultTcpipStack/sendWOL 192.168.30.255 9 54:b2:03:9e:70:fc vmk0

This uses the not supported vsish CLI to send WoL packet. The first argument is the network broadcast address, so if you have a network of 192.168.30.0/24, then the address would be 192.168.30.255. The second argument is a value of 9, which is probably related to the magic packet as you can see the same value from the wakeonlan utility abvoce. The third argument is the MAC Address of the system and finally the fourth and final argument is the ESXi VMkernel interface to send the packet out of.

Verify Hypervisor-Assisted Guest Mitigation (Spectre) patches using PowerCLI

by 80 Comments

VMware recently published a new knowledge base (KB) article 52085 that outlines instructions for enabling the Hypervisor-Assisted Guest Mitigation (CVE-2017-5715), also known as the Spectre vulnerability. This KB also provides steps to verify the updated microcode (included in the ESXi patch) has been applied along with Virtual Machine verification (those applicable) to ensure that they are seeing the new CPU features. While following the KB and patching one of my vSphere environments, I had noticed the verification steps was not only manual but it also to difficult to scale beyond a few VMs as it required customers to look for a specific set of strings from within the vmware.log file which is generated for each powered on VM, which could easily be several hundreds or thousands of VMs.

I figured there had to be a better way to help customers automate this at scale and remove the human factor. The other reason I was not fond of the current method is that it would require customers to either enable ESXi Shell/SSH access or to manually or through automation to download every single vmware.log file to inspect for specific log entries which can take quite a bit of time for any sizable environment. I had an idea on how this could be done without having to look at the vmware.log file while leveraging our vSphere APIs and did some investigation. Before proceeding further, please familiarize yourself with KB 52085. For complete background on both Spectre (CVE-2017-5753 & CVE-2017-5715) and Meltdown (CVE-2017-5754) as it relates to all VMware products, please carefully read through this top level KB 52245 which is being updated as new information is available, so you may want to subscribe to the KB for all the latest updates.

UPDATE 4 (01/23/18) - VMware has just updated KB 52345 with the current list of Intel CPUs affected by Intel Sightings. I have also updated my script to reflect all these changes. Make sure to download the latest version to ensure you have the latest changes.

UPDATE 3 (01/16/18) - I have just enhanced the script further to also collect the current microcode version running on a given ESXi host. Unfortunately, this information can only be collected when SSH is enabled and is something a user must explicitly allow. The benefit here is that Intel Sighting impact reporting is more robust as the code now checks for both impacted CPU signature as well as the microcode affected by Intel Sighting as outline in KB 52345. See below for more details.

UPDATE 2 (01/14/18) - As mentioned in the last update, I have been working on a Intel Sighting remediation script which can help customers automate the temporary workaround as recommended in KB 52345. Please see this blog post for complete details.

UPDATE 1 (01/13/18) - VMware just published a new KB 52345 outlining certain Intel Broadwell and Haswell CPUs being affected by Intel Sightings after applying latest microcode updates. Please refer to the KB for the complete details. I am currently working on a script to help with the remediation as the remediation method outlined in the KB would require customers to enable SSH access and manually update /etc/vmware/config. In the meantime, I wanted to provide a way for customers to easily identify whether their system are affected by Intel Sightings and thanks to community member Adam Robinson who just submitted a patch this morning to update my existing script to include these details. I have also added the CPU model to the output as additional information.

Note: This script only provides information about your existing vSphere environment, it does not make any changes or provides any remediation steps, please follow the KB for those instructions.

The PowerCLI script is called VerifyESXiMicrocodePatch.ps1 and it contains the following two functions:

  • Verify-ESXiMicrocodePatchAndVM
  • Verify-ESXiMicrocodePatch

[Read more...] about Verify Hypervisor-Assisted Guest Mitigation (Spectre) patches using PowerCLI

How to clear the ARP cache in ESXi prior to vSphere 5.5

by 3 Comments

Yesterday, I wrote an article about a new ESXCLI command that will be available as part of the soon to be released vSphere 5.5 release which allows a user to clear the ARP cache on an ESXi 5.5 host. It was my understanding that with past releases of ESXi, that it is not possible to clear the ARP cache. While working on that article, I came across an internal thread and learned that it was possible to clear ARP entries prior to ESXi 5.5, however the method is not as ideal as using the new ESXCLI command.

Disclaimer: This is not officially supported by VMware, please use at your own risk

In ESXi 5.1, you can list the current ARP entries for an ESXi host by running the following ESXCLI command:

esxcli network ip neighbor list

To clear a particular ARP entry, you will need to use the unsupported vsish interface. To delete a specific ARP entry, you will need to run the following command:

vsish -e set /net/tcpip/v4/neighbor del [IP-ADDRESS]

Here is a screenshot of listing the current ARP entries using ESXCLI and then deleting one of entries using vsish:

As mentioned in my previous article, I am glad we have made this into an official command in ESXCLI 5.5, but if you are in a crunch you can still clear an ARP entry if you are not running ESXi 5.5 using vsish.

What’s New in VMware Vsish for ESXi 5.1

by Leave a Comment

While going through and cleaning up my ghettoSkunkworks projects folder before going on PTO, I came across this little post which I must have forgotten to publish. With the latest release of ESXi 5.1, there are now a total of 162 new vsish configuration parameters, with 63 of those being hidden parameters.
***As usual with any hidden configurations, please be careful and use at your own risk as the vsish interface is not officially supported by VMware***
Here is the complete list of new vsish configurations in ESXi 5.1 - https://s3.amazonaws.com/virtuallyghetto-download/complete_vsish_config_510.html
 Additional Resources:

Configuring ESXi Power Management Policy Using the CLI

by 12 Comments

An interesting question on the VMTN forum caught my eye today, which was around configuring ESXi's Power Management Policy using the command-line via a kickstart script. I found this question to be interesting as I never had to tweak this configuration and was curious myself to see how you might be able to perform this via the command-line as I never recall seeing a command relating to the power management settings.

After a few minutes of digging, I found that the standard set of CLI's such as ESXCLI, vim-cmd, etc. do not provide a way to configure ESXi's power management settings but did find it was possible using my other favorite "not officially supported" CLI called vsish. Now, you can of course create a remote script using the vSphere API to configure this setting, but if you are looking to modify this within a kickstart script, this is route you will want to take.

UPDATE (01/12/15) - I just found out today from Engineering that it is possible to configure ESXi power management policy using ESXCLI. Though the parameters are currently set to hidden, you can use the following command to set the appropriate policy based on your enviornment.

esxcli system settings advanced set --option=/Power/CpuPolicy --string-value="High Performance"

UPDATE (11/04/14) - It turns out configuration changes made directly through vsish do not persist after a reboot, this might be problematic for most of you 😉 Luckily, Alan Castonguay who works in our GSS organization reached out and created a nice pyvmomi (vSphere SDK or Python) script that can be executed in the ESXi shell and of course it can easily be integrated into a Kickstart script. I have tested his sample script to verify its functionality and have also checked it into my Github repository so that others can benefit from. You can download the script which I have named configure_esxi_power_policy.py

If you run the script without any arguments, it will display the current power policy that has been enabled as seen in the screenshot below:

configure-esx-power-policy-0
To change the policy, you will need to specify the "shortName" power policy, in this example I want to change it from "static" to "low":

configure-esx-power-policy-1
To check whether your ESXi host supports power management, run the following command:

~ # vsish -e get /power/hardwareSupport
Hardware power management support {
CPU power management:Enhanced Intel SpeedStep(R)
Memory power management:Not available
}

To view the current power management setting, run the following command:

~ # vsish -e get /power/currentPolicy
Host power management policy {
ID: 2
Short name:dynamic
Long name:Balanced
Description:Reduce energy consumption with minimal performance compromise
}

Just like the vSphere Client, you have 4 options which maps to the "ID" property as seen above. You can get more details by querying each of the policy (1-4), here is an example:

~ # vsish -e get /power/policy/1
Host power management policy {
ID: 1
Short name:static
Long name:High Performance
Description:Do not use any power management features
}

Here's a quick table that maps the policy ID to power management policy which is the same order as shown in the vSphere Client:

Policy ID Power Management Policy
1 High Performance
2 Balanced
3 Lower Power
4 Custom

To change the power management policy, run the following command:

~ # vsish -e set /power/currentPolicy 1

So now you can integrate power management settings in your ESXi kickstart script for automated deployment and configurations!

What’s New in VMware Vsish for ESXi 5

by 2 Comments

I wrote about What Is VMware Vsish back in 2010 which included a list of 771 configuration parameters some public and some hidden. With the latest release of ESXi 5, I have compiled a list of the net new configuration parameters that comes out to the following:

Total: 232 
Public: 146
Hidden: 86

***As usual with any hidden configurations, please be careful and use at your own risk as the vsish interface is not officially supported by VMware***

Some of the interesting hidden parameters such as /VMFS3/EnableBlockDelete and /VMFS3/BlockDeleteThreshold could be useful in dealing with Dead Space Reclamation also known as the UNMAP VAAI primitive. For more details about the UNAMP feature, take a look at Duncan Epping's detailed post here.

For the complete list, please take a look at https://s3.amazonaws.com/virtuallyghetto-download/complete_vsish_config_500ga.html.