VMware: Custom ESXi boot iso bootable on Fusion, but not vSphere...

Building an embedded lab for some testing w/ NSX and everything.  Cannot clone a pre-installed ESXi host w/o some magic, so decided to utilize a simple kickstart script in an ESXi custom iso pre-mounted to my VM template.  Worked fine on Fusion, not vSphere/ESXi though...

Simply change VM Options --> Boot Options to BIOS

Fusion defaults to BIOS, which is why it worked.  I made the iso w/o UEFI options which is why it worked on fusion, but not ESXi VM.


The command I was using to make the iso was missing some key new features to make the iso UEFI bootable.
mkisofs -relaxed-filenames -J -R -o ~/Desktop/custom_esxi.iso -b ISOLINUX.BIN -c BOOT.CAT -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -eltorito-platform efi -b EFIBOOT.IMG -no-emul-boot ~/Desktop/ESXiDefaultInstall

You will have to modify two BOOT.CFG files, one in root directory, and the other in the EFI subdirectory to utilize any custom kickstart you put together.  If you only modify one, it will only point to the kickstart file when booted via BIOs and not UEFI or vice versa.

Basically, it came down to the fact that I was rebuilding the iso w/ an older command that didn't have the UEFI options.  This made my iso BIOs bootable (Fusion default), but not bootable on my ESXi VM which was set to UEFI.  Highlighted above in solutions section.  Basically my goal was to simply clone a templated VM shell w/ a local hard drive layout I needed for an Embedded vSAN lab.  The VM shell would have the iso mounted so that it would build ESXi at time of clone. 

So I needed an iso that would simply build ESXi w/ basic defaults and configure DHCP.  In the other notes section, I show how I modified the BOOT.CFG file(s) and added a KS.CFG file.  Once I found the options I was missing, my iso was now properly bootable via UEFI and BIOs.  This is a fairly easy workaround to build ESXi virtual hosts w/o having to stand up a PXE environment within an NSX bubble.

Other Notes:
mkisofs is not apart of MacOS, but you can install it via homebrew.
brew install cdrtools

/BOOT.CFG and /EFI/BOOT/BOOT.CFG (Modified kernelopt value to target CD rom and my custom KS.CFG)

rootpw superduperSecret!
install --firstdisk --overwritevmfs
network --bootproto=dhcp


Nested ESXi virtual appliances that you can customize via OVA options.

VMware: PowerNSX on Mac Invoke-nsxwebrequest unknown exception

All was well and dandy until I tried to actually "do" something.  I was trying to create a new logical switch (New-NSXLogicalSwitch) when these errors reared their ugly head:
One or more errors occurred. (The handler does not support custom handling of certificates with this combination of libcurl (7.54.0) and its SSL backend ("LibreSSL/2.0.20").) ---> System.PlatformNotSupportedException: The handler does not support custom handling of certificates with this combination of libcurl (7.54.0) and its SSL backend ("LibreSSL/2.0.20").

Windows w/ full Powershell does not have these issues.  Have yet to see if it is a thing specific to Powershell Core.  So use it if you can.

If you don't have a Windows box handy, you can modify the PowerNSX.psm module file to get around this error.  I'm unsure if it can become a permanent solution, but it effectively accomplishes the same thing as the current httpclienthandler.

Location of PowerNSX.psm file on Mac:

You need to modify line 105 from this:
ServerCertificateCustomValidationCallback = delegate { return true; };

To this:
ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

*One line and case sensitive, must be verbatim.

VMware: physical vmnic# not showing up after upgrade...

This was a weird one.  I had a couple of Dell FC630's (FX2 Blades) w/ qlogic broadcom 57810 integrated card in them.  Went to upgrade them from 6.0 to 6.5, that's when the fun began.  Before upgrade, my hosts could see them just fine.  After upgrade, they could only 'see' vmnic1.  Fresh install was also having issues.

In my case, I had to literally remove the FC630 blade from the FX2 enclosure so that all residual power would be drained.  Once done, whatever it was that was hanging the firmware for my nic finally cleared for ESXi to take control of it.


PowerCLICore: Docker: Case Sensitivity, script not running, errors.

If you've been using powershell for any period of time, you'd get used to the idea that it doesn't really care about casing.  PowerCLICore on Docker?  Yeah, it's a casing nazi...sometimes.  Now this experience was seen on a Mac.  Unsure if Docker running on linux sees this.

When working w/ cmdlets in general, you should fine.  However, if you were to query for commands related to a specific module like pester:

You'd get a blank return.  Looking at modules available via:
get-module -listavailable

Will show that pester is capitalized as "Pester" so valid get-command is:
get-command -module Pester

Long story short, if you are having issue running a script or whatnot, be sure to check your cAsInG.

Interestingly, once you do a get-command -module Pester successfully, powerclicore on docker magically doesn't care about casing after the fact.

VMware: NSX: Using PowerCLI/PowerNSX to view DFW rules in a table format.

Out-GridView Example
This was kind of a fun exercise and helpful considering the NSX plugin kinda blows, in flash client at least.  Have yet to take a look at HTML5 one that was just released.  Was asked if we could output currently configured DFW rules.  Below you will find what I slapped together.  If it's useful to you too, great.  Also, please feel free give me feedback.

It will basically give you the following:
  1. Rule Number 
    • This is kind of a guess in that it assumes that rules will pull down from API in the correct order at runtime.
  2. Rule ID
  3. Rule Name
  4. Source
  5. Destination
  6. Service Ports
  7. Action
  8. appliedTo
This script requires the following powershell modules:
  1. vmware.powercli
  2. powernsx