WilliamLam.com

Updated Nested ESXi 6.0u3 & 6.5d Virtual Appliances

by // 29 Comments

I finally found a bit of "extra" spare time to update my Nested ESXi Virtual Appliances to support some of the recent releases of ESXi, 6.0 Update 3 and 6.5d, which enables customers to easily and quickly deploy vSAN 6.6 in their environment for testing, development or learning purposes. If you have not used this appliance before, please have a look at this article which goes into greater detail on how to deploy and use the Nested ESXi VA.

As part of this update, I also spent some time looking at all the feedback that I had received from the community since releasing the VA and I took this opportunity to also add some nice enhancements that folks have been asking about 🙂 Jump towards the bottom to see what's new. To reduce the number of VA's that I need to manage and due to usage, the following VA's have recently been decommissioned. I only plan on supporting the latest versions which you can find in the links below.

Decommissioned VA's:

  • ESXi 5.5 Update 3 (Nested_ESXi5.x_Appliance_Template_v2.ova)
  • ESXi 6.0 Update 2 (Nested_ESXi6.x_Appliance_Template_v5.ova)
  • ESXi 6.5 GA (Nested_ESXi6.5_Appliance_Template_v1.ova)

New VA's:

What's New:

  • Support for DHCP 
    • I know this might sound pretty basic but before you were required to specify a static IP (even if you had DHCP). By default, you no longer need to fill out the networking section as highlighted in yellow below.
  • Support for default root password
    • You no longer need to provide root password, it will default to the famous VMware1! The issue in the past was that I had randomly generated a password which I discarded and when the customization failed, it was very difficult to troubleshoot since I do not actually have the password 😉 Hopefully we do not have any other bugs, but this will make debugging easier and also reduce the amount of input if you want to quickly spin up an ESXi instance.
  • Support for VLAN ID
    • Though not a huge number of requests, there were still of you who asked for 802.1q (trunk) support on Management VMkernel interface. This is an optional field and obviously this is only applicable if you provide a static IP Address.
  • Automatic removal of Customization VIB
    • As some of you may or may not know, the way in which these OVF properties are processed within the Nested ESXi instance is a special firstboot script which reads in these values and then applies the ESXi customization. If everything is successful, there really is no use for this to exists further and although you could set a certain advanced setting to force re-customization, it was quicker to just re-deploy. With that in mind, the customization VIB is now automatically removed once its done its job. I have included a special debug option that would allow it to not be deleted in scenarios where there are issues and we need to take a look at the state of the system. With this change, you really now have a "vanilla" ESXi instance 🙂
  • Fixed dvFilter param for eth1


Hope you enjoy some of these new updates and happy Nesting!

Auditing & Automating Disabled Protocols (TLS/SSLv3) for ESXi 6.0u3 & 6.5 using PowerCLI

by // 32 Comments

A couple of weeks back, I had received a question from one of our TAMs in regards to automating the disablement of specific TLS/SSL protocols for their ESXi 6.0 Update 3 hosts. As of vSphere 6.0 Update 3 and vSphere 6.5, customers now have the ability to completely disable TLS 1.0, TLS 1.1 and SSLv3 using the new TLS Reconfiguration Tool. Mike Foley did a nice write up here if you are interested in more details.

The TLS Reconfiguration Tool works well if you have the same version of vSphere for both your vCenter Server and ESXi host, but has challenges when you are in a mixed environment like this particular customer. In their environment, they are running vCenter Server 6.5 and ESXi 6.5 Update 3 which prevented them from using the TLS Reconfiguration Tool as this is a limitation with the tool today.

UPDATE (05/11/17) - Added support for ESXi 6.5 hosts as well

Given the TLS Reconfiguration Tool was written in Python, I was able to take a closer look at its implementation and I found that the settings that controlled the disabled protocols were just merely a few ESXi Advanced Settings which meant that this could be automated using standard vSphere Automation Tools that our customers were already familiar with. As part of this exercise, I also discovered the tool currently does NOT support disabling TLS/SSLv3 protocols for the Small Footprint CIM Broker (SFCB) service which is also required if you want to be in full compliance for a particular TLS protocol. Although there is not a direct SFCB API that allows you to manage the sfcb.cfg configuration file, there is still a way we can automate this without requiring SSH to the ESXi host which would technically be the alternative. Lastly, I was a bit surprised to see the TLS Reconfiguration Tool did not have a "query" option for listing the current disabled protocols for all ESXi hosts, but they do have it for vCenter Server itself.

To help this particular customer and others who may have specific TLS compliance requirements, I have created the following PowerCLI script called ESXiDisableProtocolConfiguration.ps1 which includes the following two functions:

  • Get-ESXiDPC - Retrieve the current disabled protocols for all ESXi hosts within a vSphere Cluster
  • Set-ESXiDPC - Configure the specific disabled protocols for all ESXi hosts within a vSphere Cluster

[Read more...]

ESXi Learnswitch – Enhancement to the ESXi MAC Learn DvFilter

by // 23 Comments

The ESXi MAC Learn dvFilter Fling was released a little over two years ago and it has become a must have when it comes to running our ESXi Hypervisor within a VM, also referred to as Nested ESXi. The reason this Fling has become such a popular hit amongst our customers and partners is that it greatly improves the performance when “Promiscuous Mode” is enabled on a Virtual or Distributed Virtual Portgroup, which is a requirement for using Nested ESXi. Although this Fling works great, there are a couple of limitations with this solution today. The first of which is called out in the original Fling release notes, that once a MAC Address has been learned, it never ages out which is not ideal for long running Nested ESXi environments that generates a large amount of new MAC Addresses. The second, is the lack of vMotion support where the learned MAC Address table is not transfered to the destination ESXi host and must be re-learned.

To help address both of these limitations, the folks over in the Network and Security Business Unit (NSBU) have been working hard to improve upon the existing solution and have developed a new native MAC Learning VMkernel module called the Learnswitch. This new Learnswitch not only helps improves Nested ESXi workloads but it can also potentially benefit other workloads such as Nested Containers or other 3rd Party network inspection software. One immediate difference from the previous MAC Learn dvFilter solution is that rather than operating on the Network IO Chain, the filtering is now performed within the outer virtual switch layer itself which will provide some additional performance gains. The other added benefit from an internal VMware standpoint is that the Learnswitch is now vmkapi compatible, which means we will have a better backwards compatible story for supporting old releases of ESXi. One downside to this new solution compared to the previous one is that because the dvFilter operated below the virtual switch layer, it could support both a Virtual Standard Switch as well as the Distributed Virtual Switch. With the new Learnswitch, a Distributed Virtual Switch will be required. If you currently do not meet the requirements of the new Learnswitch, you can continue using the dvFilter, but it is recommended that you do not mix both on a single system but you can definitely make use of both solutions across different ESXi hosts depending on the constraints of your environment.

Here are some of the new capabilities provided by the new Learnswitch module:

  • Overlay Network based that learning and filtering are done in Etherswitch forwarding check
  • MAC Address learning is based on VLAN ID or VXLAN ID on uplink and leaf port
  • Packet is filtered on uplink and leaf port if the MAC is learned on a different port
  • MAC Address table size is 32k per system
  • MAC Address aging support with default aging time of 5 minutes and configurable
  • Unknown unicast packet is flooded by default and configurable to drop
  • vMotion support that the MAC table learned on the port is transferred to destination host and RARP packet is sent
  • Standalone VMkernel module available as a VIB
  • net-learnswitch CLI to display MAC Address table, configuration and stats

[Read more...]