Skip to content

VMWare Support

A collection of tools for managing VMware vSphere ESXi nodes via Digital Rebar Provision (DRP) workflows and content. This plugin provides content and pieces for managing ESXi infrastrcuture. In addition to standard VMware release BootEnvs for various ESXi versions, custom vendor BootEnvs are also included.

VMware vSphere ESXi installs can be highly customized via the use of DRPs templating constructs to create a complex Kickstart that is capable of doing deep configuration of the ESXi node.

Overview of Usage

Starting in the VMware plugin version 2.9.0 and newer, there is a much simplified Workflow use pattern. Previously, there were several Workflows and Stages that were each used for a specific version of the VMware ISO to be installed. This created a sprawling mess.

Starting with v2.9.0 plugin - you now have only one example Workflow and stage that uses a set of Params to define what to deploy to your machines. In addition, you can let the system select a default version based on the the Classification Vendor/Model information of your machines, by use of a Map.

Warning

Moving to the v2.9.0 version plugin will require some manual upgrade steps. Please see the UPGRADE notes below.

Basic Usage

For basic usage, and to obtain the latest VMware generic ISO BootEnv installation, simply use the esxi-install workflow.

Note

The 'esxi-install' workflow must be run in the Sledgehammer (Discovery) image environment to transition the Machine to the appropriate ESXi bootenv installation.

Note

The first stage of the workflow is 'prep-install' which WILL WIPE the disks in preparation of the installation.

This workflow uses the following Params:

  • vmware/esxi-version: set to select-vendor, or to a precise BootEnv that exists on the system (eg esxi_670u2-13006603_vmware), this is an enum type of curated an supported BootEnvs by RackN
  • vmware/esxi-version-override: if the curated list of BootEnvs does not support your needs (you've installed custom BootEnvs), then setting this value will override the enum list in vmware/esxi-version - the specified BootEnv must exist, be valid, and the ISO contents exploded and available somewhere
  • vmware/esxi-version-vendor-map: this is a mapping of which BootEnv to use by default when a machine Vendor and Model has been automatically Classified - it allows for single workflows to address heterogeneous pools of hardware - see the Param documentation below for more details
  • esxi/patch-map: allows the operator to specify additional patches to install after the BootEnv is installed via the ISO contents - this is useful for VMware Cloud Foundation (vCF) HCL compliance installations that require additional patch levels be installed in preparation for vCF cluster builds.

Please review below documentation for additional details on the above pieces.

Advanced Usage

Setting the vmware/esxi-version Param to select-vendor will enable automatic selection of the ISO based on the Vendor and Model (if appropriate) of the hardware, dynamically. This pattern allows operators to have a pool of heterogenous hardware, and map VMware ESXi ISO versions to the vendors, allowing for appropriate custom vendor ISOs to be used for each hardware type.

This map is maintained in the vmware/esxi-version-vendor-map, which carries a default set defined by RackN. Should you want to specify precise versions to use, you can set this Param to a map structure of your choosing. Set this directly on the Machine as a Param, or via Profiles that are added to the machine (including global, if appropriate).

Patching ESXi Systems at Install Time

The RackN VMware plugin also supports applying a patch version to the base install ISO at installation time. The patching system relies on two separate sets of maps to specify where to find the Patches and related information (the esxi/patch-map, and the actual patch to install (via the vmware/esxi-version-vendor-map param).

The Patch Map defines the patch name based on the VMware "Build Number", which also serves as the index for the URL location, hash to validate the patch, and an optional custom location for finding the patch. Please see the individual esxi/patch-* named Params for more details.

VMware maintains their patch download URLs behind a CGI gateway that does not expose a direct download URL link. RackN can not provide a direct download link in the individual Patch download locations. Please follow the below steps to acquire patches:

  1. go to: https://my.vmware.com/group/vmware/patch#search
  2. login with your VMware account
  3. select "ESXi (Embedded and Installable)"
  4. select the version of ESXi that the patch applies to
  5. then in the "Enter Build Number" - put the build number ID which can be referenced in the esxi/patch-map Param
  6. hit search
  7. you'll get a table of results - cross reference the correct Build ID - and click on the "Download" button they provide
  8. send a gentle note to VMware to modernize their download process

Adding Custom BootEnvs (VMware ESXi versions)

At RackN, we try to keep up with the latest set of VMware ESXi versions, but the reality is ... we won't succeed. As such, you may need to inject new BootEnvs in to the system, which support your specific Vendor and/or VMware ESXi version needs. This content pack supports adding in new BootEnvs (VMware ESXi versions), and using the above set of Params and Workflow control to deploy them to your machines.

Additionally, custom created vSphere ESXi ISOs can be converted to Digital Rebar content packs with this process.

There is a script that is distributed with the vmware plugin named make-esxi.sh. This script combines the previous two scripts capabilities in to a single tool. The previous scripts were make-esxi-bootenvs.sh and make-esxi-content-pack.sh.

Note

See the V4.3.0 Upgrade Notes for details on dealing with this transition

The script is designed to allow you to specify what ISO images to create either a standalone mini content pack from, or to just generate appropriate bootenvs and a boot.cfg template to match it. The mini content pack approach is designed to work in conjunction with the vmware plugin, not to replace it. In content pack mode, appropriate workflows and stages will also be generated in addtion to the bootenvs and boot.cfg templates.

RackN uses this same script to generate the vmware plugin_provider content pieces (bootenvs and boot.cfg templates).

Part of the process includes generating appropriate meta data information about the bootenv and ISO version information. Unfortunately, because the ISO file names and internal ISO meta data information is wildly inconsistent, it's impossible to dynamically generate structured and useful data.

As a consequence, there is an internal array map (named ISO_MAP[]) which contains all generated bootenv meta data details. This is a curated list that is amended as RackN adds more ISOs to the support list for the vmware plugin_provider.

If you are just testing one-off or a small handful of ISOs for installation, it may not be necessary to worry about this. Just use the '-g' (Generated) mode of the script, and minimal meta data will be built. If you wish to maintain a more comprehensive content pack for longer term use with curated bootenvs, we highly recommend you generate an appropriate ISO_MAP set of values. The ISO_MAP can be contained in a separate reference file independent of the script.

There are two Usage related flags to the script for additional information and details on how to use it. Please see those output details for more usage, notes, and examples.

# the two usage flags to the make-esxi.sh script
cd /var/lib/dr-provision/tftpboot/files/plugin_providers/vmware
./make-esxi -u         # switch argument Usage
./make-esxi -x         # eXtended usage output, includes notes and examples

Note

IF YOU NEED ISO VERSIONS WE HAVE NOT ADDED ... please contact RackN, we would like to keep the vmware plugin as up to date as possible for our customer requirements. We will continue to add new versions as we can. You will receive the benefit of this content being "off-the-shelf" and not requiring additional custom content to support ESXi environments.

Managing Your ESXi Passwords

There are a few options you have for setting/defining the password(s) that are set on your installed ESXi instance.

During the ESXi installer process (kickstart/weasel), the shell (Alt-F1) is the stock/standard ESXi set (user "root", no password).

If you take no actions, the default password will follow all standard bootenv passwords see Default Passwords for details.

To set custom passwords, you have the following options, the items listed first, will take precedence over subsequent items:

  1. Set the provisioner-default-password-hash to a SHA512 sum value.
  2. Use the esxi/insecure-password Param set on a machine (directly or via a Profile), with a clear text password. This will be converted to a SHA512 hash and fed to weasel for the installed ESXi password.
  3. You can have the system dynamically generate a random VMware formatted valid password for every single ESXi instance installed. To use this, set the param esxi/generate-random-password to true. This can only be run as a preparatory stage in Sledgehammer.

The generate random use case is designed to allow your infrastructure to have secure per-machine passwords. The expectation is that you will move these in to a centrally managed secrets system (eg vault or password keeper) for consumption by other automated systems.

Please see the per-Param documentation below for more details on the above methods.

NOTES ON UPGRADING TO v4.4.0 Plugin

In the v4.4.0 plugin_provider the rackn agent known as drpy is now provided as a VMware Partner Supported package which requires building a custom ISO to include the packages needed. RackN provides a build script to produce the ISO, but it must be run from Windows and depends on PowerCLI from VMware. To make this process easier for our customers we include a link to a pre-built ISO for many common releases.

NOTES ON UPGRADING To v4.3.0 Plugin

In the v4.3.0 plugin_provider the previous two (or three!) scripts:

  • make-esxi-bootenv.sh
  • make-esxi-bootenvs.sh
  • make-esxi-content-pack.sh

Have been consolidated in to a single script named make-esxi.sh. The Plugin Provider update process does not remove these scripts on update. We highly recommend that you remove the old versions of the above listed scripts to prevent future confusion.

You will need to manually remove the old versions of the scripts. Log in to the shell of your DRP Endpoint, and perform the following tasks.

# remove old script versions - assume "default production" install location
cd /var/lib/dr-provision/tftpboot       # adjust to your 'tftpboot' directory location
FILES="files/plugin_providers/vmware/scripts/make-esxi-bootenvs.sh
      files/plugin_providers/vmware/scripts/make-esxi-content-pack.sh
      make-esxi-bootenv.sh make-esxi-bootenvs.sh make-esxi-content-pack.sh"

for F in $FILES; do [[ -r "$F" ]] && rm -i $F || echo "Skipping - '$F' file found"; done

Additionally, you may wish to symbolically link the new replacement script to a system PATH location, as follows:

ln -s /var/lib/dr-provision/tftpboot/files/plugin_providers/vmware/scripts/make-esxi.sh /usr/local/bin/

NOTES ON UPGRADING To v2.9.0 Plugin

The new version selector features are being released in the plugin version v2.9.0. If you have used the previous v2.8.0 or older versions, you will need to perform some basic maintenance to install this version, as there are incompatible changes. Below are some notes related to the upgrade. If you run in to issues, please contact RackN as quickly as possible, don't waste your time trying to sort it out.

  1. Remove all vmware/esxi-version Params from your Machines or profiles. The naming structure of the BootEnvs has changed to be more structured and predictable. This causes the Param enum structure from the OLD versions to NOT BE COMPATIBLE with the new.
  2. Your "exploded" BootEnvs on disk or in your esxi/http-mirror location needs to change. If you are not using the http mirror method, you can simply delete the tftpboot/esxi-* directories relating to your existing ISOs, then restart the DRP service.
  3. Insure your original ISOs still exist in the tftpboot/isos/ directory, for them to be re-exploded to the new BootEnv names.
  4. Remove the existing VMware plugin, then add the new one - do not perform an upgrade/install of it.

Generally speaking we try to avoid, impacting upgrades like this with content, but sometimes there are compelling reasons to make breaking changes. In this case we move to a much cleaner and easier to support method for deploying ESXi, gain incredibly powerful auto-magic deployments based on hardware vendor, and simplify and standardize the naming structure of the BootEnvs.

DEPRECATED BOOTENVS

To support a successful upgrade from the v2.8.0 to v2.9.0 vmware plugin, the old BootEnv names must be mainatined. If they are referenced via Workflow or as configuration on Machine Objects, or other places in the system, you will not be able to successfully update to the v2.9.0 plugin version.

The following list of BootEnvs are considered deprecated, and will be removed in a future release. Probably very very soon (v2.10.0 plugin versions). You must change any references to the following BootEnvs in your DRP endpoint, prior to your next upgrade:

  • esxi-550u3b
  • esxi-6.7.0-update1-10302608-custom-hitachi_0200_Blade_HA8000
  • esxi-6.7.0-update1-10302608-custom-hitachi_1200_HA8000VGen10
  • esxi-6.7.1-10302608-nec-6.702
  • esxi-6.7.1-10302608-nec-gen-6.7
  • esxi-600u2
  • esxi-600u3a
  • esxi-650a
  • esxi-650u2
  • esxi-670
  • esxi-670u1
  • esxi-670u2
  • esxi-dellemc-esxi-6.5u2-10719125a07
  • esxi-dellemc-esxi-6.7u1-10764712-a04
  • esxi-fujitsu-vmvisor-installer-6.7-10
  • esxi-hpe-esxi-6.7.0-update1-iso-gen9p
  • esxi-lenovo_esxi6.7u1-10302608_201810
  • esxi-vmware-esxi-6.7.0-10302608-custom-cisco

The new bootenv naming scheme is designed to be more machine parsable, and no longer uses the vendor ISO meta information as it is wildly inconsistent and sucks.

The replacement BootEnv names are below, and you should be able to determine the mappings between the names.

  • esxi_550u3b-3248547_vmware
  • esxi_600u2-3620759_vmware
  • esxi_600u3a-5572656_vmware
  • esxi_650a-4887370_vmware
  • esxi_650u1-7388607_hpe
  • esxi_650u2-10719125-A07_dell
  • esxi_650u2-8294253-A00_dell
  • esxi_650u2-8294253_vmware
  • esxi_670-8169922_vmware
  • esxi_670u1-10302608_cisco
  • esxi_670u1-10302608_fujitsu
  • esxi_670u1-10302608_hitachi_blade-ha8000
  • esxi_670u1-10302608_hitachi_ha8000v-gen10
  • esxi_670u1-10302608_lenovo
  • esxi_670u1-10302608_nec
  • esxi_670u1-10302608_vmware
  • esxi_670u1-10764712-A04_dell
  • esxi_670u1-11675023_hpe_gen9plus
  • esxi_670u2-13006603_cisco
  • esxi_670u2-13006603_hitachi
  • esxi_670u2-13006603_hpe
  • esxi_670u2-13006603_vmware
  • esxi_670u2-13473784_fujitsu
  • esxi_670u2-13644319_nec_r120h-t120h-r110j
  • esxi_670u2-13644319_nec_standard
  • esxi_670u2-13981272-A02_dell
  • esxi_670u2-13981272_lenovo

Note

There may be many more bootenv names than listed above, if support for newer vendor ISOs and/or VMware versions are released.

Note

It is advisable to use the esxi-install Workflow and the esxi/select-version-map Param to control your ESXi bootenv installation.

ESXi Agent/Runner Information

VMware ESXi environments are for the most part "closed appliances", and compiling third party tools for these environments is not an easy process. Consequently, the Golang based compiled Agent/Runner (drpcli) can not be cross compiled to run in the ESXi operating environment. RackN does build and maintain a Python3 capable Agent/Runner to support Workflow operations in the ESXi install environment (Weasel kickstart) and as a post-installed Agent for executing Workflow in installed systems.

There are two primary components that must be installed to support Workflow in the ESXi environment:

  • DRPY ("derpy") Agent - an ESXi VIB module - installs the Python3 based tools to support Workflow/Stage execution
  • Firewall-VIB - an ESXi VIB module - enables persistent firewall port access from the installed ESXi environment to the DRP API port

If you are using the Workflow system to mark machines as "complete" for install tracking purposes, you must also set the esxi/skip-notify Param value to true.

To install the ESXi Agent/Runner, you must also install the Firewall-VIB module, or arrange to disable the ESXi built-in firewall system.

Adding Custom Kickstart Sections

Digital Rebar Provision provides on-the-fly customization of the built Kickstart through the use of injecting Templates in to the core Kickstart file, and also providing dynamic information available on the DRP endpoint, in to the Templates.

Note

It is HIGHLY RECOMMENDED to use the RackN Workflow and Stages to add customizations to the install process, and to NOT INJECT custom kickstart templates. Please see the "ESXI Agent/Runner Information" section.

ESXi kickstarts support three additional sections (or phases) that extra actions can be taken during the installation process:

  • Pre Stage (%pre)

    Specifies a script to run before the kickstart configuration is evaluated. For example, you can use it to generate files for the kickstart file to include.

  • ESXi Installation Stage

    Uses Kickstart for automating the installation; see Vmware Kickstart Documentation for more details.

  • Post Stage (%post)

    Runs the specified script after package installation is complete. If you specify multiple %post sections, they run in the order that they appear in the installation script.

  • Firstboot Stage (%firstboot)

    Creates an init script that runs only during the first boot. The script has no effect on subsequent boots. If multiple %firstboot sections are specified, they run in the order that they appear in the kickstart file.

DRP's "vmware" content allows you to inject custom %pre, %post, and %firstboot scripts in to your installation kickstart. It is up to the operator to understand the ordering and proper usage of these scripts.

To do so, simply create Templates with your Kickstart snippets defined as you desire. Then use the esxi/ks-custom-sections Param structure to include the appropriate scripts in your kickstart.

Note

The %pre %post and %firstboot separators will be injected into the Kickstart file for you (do NOT include them in the template).

Example Param definition:

YAML:

- "pre-busybox"
  - "my-pre-busybox-chunk1.ks.tmpl"
  - "my-pre-busybox-chunk2.ks.tmpl"
- "post-python"
  - "my-post-python3-chunk2.ks.tmpl"
- "firstboot-busybox"
  - "my-fistboot-busybox-chunk1.ks.tmpl"

JSON:

{
  "firstboot-busybox": [
    "my-fistboot-busybox-chunk1.ks.tmpl"
  ],
  "post-python": [
    "my-post-python3-chunk2.ks.tmpl"
  ],
  "pre-busybox": [
    "my-pre-busybox-chunk1.ks.tmpl",
    "my-pre-busybox-chunk2.ks.tmpl"
  ]
}

Warning

None of the above reference templates exist in this plugin. You must create them as appropriate for your use cases.

You may also create templates that carry kickstart command directives, to customize the main body of the kickstart. Use the esxi/ks-custom-kickstart param to specify the additional templates with kickstart directives to inject. These will be placed after the esxi-network-ks.tmpl, but before any of the %pre, %post, and/or %firstboot ections are injected.

Example:

esxi/ks-custom-kickstart:
  - my-kickstart-chunk1.ks.tmpl

The above examples will generate a kickstart that looks similar to below:

# DRP provided kickstart opening statements
<template default statements go here>

# DRP provided network configuration template
<esxi-network-ks.tmpl>

# example "kickstart" customization template
<my-kickstart-chunk1.ks.tmpl>

# DRP provided kickstart template pre/post/firstboot "stock" sections
<esxi-notify-drp-py3.tmpl>
<esxi-preserve-logs.tmpl>
<esxi-enable-shells.tmpl>

# example custom sections to add
# firstboot-busybox
%pre --interpreter=busybox
<my-firstboot-busybox-chunk1.ks.tmpl>

# post-python
%pre --interpreter=python
<my-post-python3-chunk2.ks.tmpl>

# pre-busybox
%pre --interpreter=busybox
<my-pre-busybox-chunk1.ks.tmpl>
<my-pre-busybox-chunk2.ks.tmpl>

Network Configuration Options

The VMware plugin from RackN supports managing relatively complex network scenarious around your VMware ESXi infrastructure. There are three places within the provisioning stages that network configuration changes can be made to support different operational models.

The three primary configuration points for network settings are explained below. In all cases, we assume that the PXE start process is assigned an IP address from your DHCP infrastructure - either from Digital Rebar Provision itself, or other external DHCP services.

  1. Initial kernel network configuration. Initial DHCP/PXE services may be on an isolated network from the provisioning networks. These settings are controlled by passing values to the kernel at initial load time, via use of the kernel-options parameter.

    An example: ip=10.10.10.10 netmask=255.255.255.0 gateway=10.10.10.1 vlan=10

  2. Once the initial kernel has booted, the kickstart environment can be plumbed with a set of network configuration options. See the esxi/network-kickstart-type Param documentation for details on configuring the network at this stage.

  3. Once a machine has finished installing, and subsequently boots in to it's installed operating system; it is possible to again specify different network configurations.

    This may be necessary in the case of a Provisioning network transition to a Production network configuration post-install.

    To customize the network configuration post-install, please see the esxi/network-firstboot-type parameter for options.

Some sample scenarios and how you need to configure for those use cases are listed below.

Simple DHCP Only Setup

If you are trying to simply obtain a DHCP configuration at boot time, and preserve that IP through the install and frist boot of the installed OS, you do not need to do anything. The default behavior will be to obtain DHCP and preserve it through the install.

DHCP on PXE; Configure Manual IP (kickstart and installed OS)

If you intend to acquire an IP address during initial PXE boot of the Machine, but then transition to a Static (manually) configured network configurutation during the Kickstart installation and as the final installed network config, use the following steps:

  1. Do not set any values for kernel-options
  2. Set the esxi/network-kickstart-type appropriately
  3. Follow the documentation for that Param.

DHCP ON PXE; Retain for Kickstart; Installed OS Different

If your provisioning network is defined by the PXE DHCP network configuration, but you wish to transfer the installed OS (on first boot), to a new network configuration, use the following setps:

  1. Do not set any values for kernel-options
  2. Set the esxi/network-firstboot-type appropriately
  3. Follow the documentation for that Param.

VLAN Tagged Interfaces

VLAN tagged frames can be set at any of the three primary stages of the provisioning process outlined above. Set the appropriate options for either of the following stages:

Kernel boot/kickstart VLAN tagged Set the kernel-options param to include the vlan=N setting, where N is the VLAN ID from 1 to 4096.

Kickstart Network and/or Firstboot Network VLAN tagged Set the Param esxi/network-*-vlan Param for the appropriate stage.

Packet MTU Size

Custom MTU (maximum transmission unit) frame sizes for packets can be set. This is for the Management Network (eg "vmnic0"/"vmk0") MTU setting. To set the MTU size, set the following Param to your specified value:

  • esxi/network-firstboot-mtu

Note

The MTU size setting change currently is only supported for the "firstboot" (final installed) stage of the configuraiont; it is not supported during the kickstart/weasel install process.

DNS, Search Domains, NTP Settings

To customize network configurations for DNS and NTP settings, please see the drp-community-content Params:

  • dns-servers
  • ntp-servers
  • dns-search-domains

Additionally, a custom NTP configuration template can be provided to completely override the (relatively simplistic) default NTP settings supported by this content. To override the template follow the below steps:

  1. Create a new Template with your NTP configuration.

  2. (optional) You can use the existing ntp-servers Param similarly to the RackN supplied content, by reviewing the following example.

    restrict default kod nomodify notrap noquerynopeer
restrict 127.0.0.1
{{range $key, $ntp := .Param "ntp-servers" -}}
server {{ $ntp }} iburst
{{end -}}

  3. Set the esxi-ntp-conf Param with the name of your NTP template you created above.

Licensing ESXI During Install

Use the esxi/license Parameter to set a License to be used during installation to enable licensed use of ESXi.

The following documentation defines the various components of the vmware content and how to use them.

Various Error Messages You May See

If you are regularly installing ESXi systems and observing the installation from the systems console (keyboard, video, mouse, etc.), you may observe a few error messages that the Weasel installer kicks out. These are considered "normal" and are documented here just in case you go looking for them.

Deleting vmk0 Management Interface

Error Message:

Deleting vmk0 Management Interface, so setting advIface to NULL

Explanation:

This is generally a non fatal issue, and due to forcing override on the default gateway during the Weasel installation configuration stages. You should be able to safely ignore this error.

Validation Disabled

Error Message:

Attempting to install an image profile with validation disabled.  This may result
in an image with unsatisfied dependencies, file or package conflicts, and potential
security violations.

Explanation:

VMware VIBs (software installer bundles) have four levels of "trusted" levels. Currently, the RackN Firewall and DRPY Agent VIB are set at CommunitySupported level. This means that if the ESXi system is installed to accept software any higher level, then this message will be displayed.

RackN is a Partner with VMware, however, we do not have certifications for these packages yet. Until then, you'll have to live with this error message.

For more details on VMware Acceptance Levels, please see:

Scratch Partition Location

Error Message:

Logs are stored on a non-persistent storage.  Consult product documentation to configure a
syslog server or a scratch partition.

Explanation:

This is an expected message due to the installer (Weasel) architecture. The installation is performed from a memory backed filesystem, and any installer logs are written to this location. When you reboot, the installer logs are nuked.

To preserve the logs, RackN copies them to /vmfs/volumes/datastore1/install-logs/ for post-install review if there are any questions on the installer actions, or errors in the installation.

At some future point, these logs may be forwarded to the Endpoint and accessible within the Job Logs subsystem.

For more details on Scratch partition, please see:

Note

Unfortunately, the scratch partition can't be located within the Weasel installer, so this error message will always be present.

Error Opening tools.t00

Error Message:

Error (see log for more info):
cannot open file
[Errno 2] No such file or directory: '/tardisks/tools/t00'

Explanation

VMware vSphere 7.x ISO disks now require all modules specified in the manifest to be loaded. This means if the esxi/skip-tools is set to true, that module (tools.t00) will not be served to the Weasel install environment.

You must set:

esxi/skip-tools: false

To insure that tools.t00 modules is properly loaded. You can no longer skip loading this module.

Starting in v4.4 of the VMWare plugin many of the ISO files now provide a -no-tools ISO file and matching bootenv you can use.

Building ESXi ISOs With RackN Agent Embedded

As mentioned above in the upgrading to v4.4 notes a Windows machine will be required to build the ISO. On the Windows machine you need to have powershell, and powercli from VMware. Its fine to use your normal user. Admin privs were not needed in testing. The powercli script to build the iso is part of the vmware plugin.

PS C:\\Users\\errr> Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false # only needed the first time you use powercli
PS C:\\Users\\errr> mkdir rackn
PS C:\\Users\\errr> cd rackn
PS C:\\Users\\errr\\rackn> Invoke-Webrequest -Uri http://RS_ENDPOINT:8091/files/plugin_providers/vmware/scripts/build_iso.ps1 -Outfile build_iso.ps1
PS C:\\Users\\errr\\rackn> build-iso.ps1 -exportpath C:\\temp\\isos\\7-0 -rackNolbDir C:\\temp\\olbs\\rkn-7-0 -esxiOlbDir C:\\temp\\olbs\\7-0

Once that is done a command prompt should be returned, but sometimes it doesnt so after 30-60 seconds if you dont have a prompt hit enter and it should show up if its done if not just wait a bit more. The process takes under 1 min in most cases. This process will build an ISO & OLB for every profile listed in the ESXi OLB.

Removing DRPY Agent

The vmware plugin now includes a script that can be used to remove the DRP Agent. To use the script you will need to copy the script to the ESXi host, then run the script from the ESXi command line. Below will outline the steps an operator can take

# From the ESXi host as root
wget http://RS_ENDPOINT:8091/files/plugin_providers/vmware/scripts/remove_drpy.py
chmod +x remove_drpy.py
./remove_drpy.py

Once complete drpy and the firewall rule vib required by drpy will be removed.