Skip to content
Explore 2025 Session

Getting Started

What is Holodeck?

Holodeck is a toolkit designed to provide a standardized and automated method to deploy nested VMware Cloud Foundation (VCF) environments on a VMware ESX host or a vSphere cluster. These environments are ideal for technical capability testing by multiple teams inside a data center to explore hands-on exercises showcasing VCF capabilities to deliver a customer managed VMware Private Cloud. Holodeck is only to be used for a testing and training environment; it is ideal for anyone wanting to gain a better understanding of how VCF functions across many use cases and capabilities. Currently, there are two different versions of the Holodeck supported - Holodeck 5.2x supporting VCF 5.2.x and Holodeck 9 supporting VCF 5.2.x and VCF 9.x.

Advantages of Holodeck

While there are multiple ways to deploy nested VCF environments, this can be time consuming and may require specific settings to ensure optimal experience. That's where Holodeck comes in. Some of the challenges Holodeck helps overcome are:

  • Reduced hardware requirements: When operating in a physical environment, VCF requires four vSAN Ready Nodes for the management domain, and additional hosts for adding clusters or workload domains. In a nested environment, this same four to eight hosts are easily virtualized to run on a single ESX host or a vSphere cluster.

  • Self-contained services: Holodeck comes with built-in common infrastructure services, such as NTP, DNS, AD, Certificate Services and DHCP within the environment, removing the need to rely on data center provided services during testing. Each environment needs a single external IP.

  • Isolated networking: Holodeck removes the need for VLAN and BGP connections in the customer network early in the testing phase.

  • Isolation between environments: Each Holodeck deployment is completely self-contained. This avoids conflicts with existing network configurations and allows for the deployment of multiple nested environments with no concerns for overlap.

  • Multiple VCF deployments on a single VMware ESX host of sufficient capacity: A typical VCF Standard Architecture deployment of a four-node management domain and three-node VI workload domain requires approximately 48 CPU cores, 650 GB memory and 2.2 TB disk for VCF 9.1. See the Pre-requisites section for full resource requirements across all supported versions.

  • Automation and repeatability: The deployment of a nested VCF environments is almost completely hands-off, and easily repeatable.

Holodeck Environment Overview

Each Holodeck environment contains:

  • Enhanced Holorouter appliance (Photon OS based) with built-in networking services:
    • DNS, DHCP, NTP, Proxy, dynamic routing (BGP), L2 switching
    • New: HashiCorp Vault for secrets management
    • New: Authentik SSO for identity and access management
    • New: Technitium DNS for advanced DNS capabilities
    • Optional webtop (virtual desktop) capability with HTTPS endpoints
  • Enhanced VCF Support: VCF 9.1.0.0, 9.0.x, 5.2.x and VVF 9.1.0.0 deployments
  • vSAN ESA and OSA support with enhanced validation
  • Enhanced depot support: Online and offline depot with proxy for VCF Installer and improved validation
  • Management Domain deployed with 4 nested hosts as vSAN ready nodes:
    • VCF Installer, VMware vCenter, VMware NSX, VCF Operations, VMware SDDC Manager, VCF Automation (optional)
  • Enhanced Workload Domain with 3 nested hosts as vSAN ready nodes:
    • VMware vCenter, VMware NSX, and Supervisor (optional)
  • Enhanced Supervisor deployment: Management or workload domain with VNA (distributed) or Edge (centralized) networking modes
  • Enhanced NSX Support:
    • Edge Cluster deployment in management and/or workload domain
    • New: Virtual Network Appliance (VNA) cluster support for distributed networking
  • Comprehensive Day 2 Operations:
    • VCF Automation deployment via VCF Operations Manager
    • VCF Automation All Apps Org deployment
    • Supervisor deployment with networking mode selection
    • Deploy additional 3-node vSphere clusters in management or workload domains
    • Deploy new nested ESXi hosts with custom specifications
  • Enhanced networking: Custom CIDR, VLAN, and DNS domain support
  • Provision-only mode: Deploy VCF Installer and ESX hosts for greenfield experience
  • Enhanced security: HTTPS everywhere, automated certificate management
  • A Holorouter appliance (photon OS based) with built-in networking services such as DNS, DHCP, NTP, Proxy, dynamic routing (BGP), L2 switching and optional webtop (virtual desktop) capability
  • Support for VCF and VVF deployments
  • vSAN ESA and OSA support
  • Support for online and offline depot with proxy for VCF Installer
  • Management Domain deployed with 4 nested hosts deployed as vSAN ready nodes including VCF Installer, VMware vCenter, VMware NSX, VCF Operations, VMware SDDC Manager, VCF Automation (optional)
  • Optional Workload Domain deployed with 3 nested hosts deployed as vSAN ready nodes including VMware vCenter, VMware NSX and Supervisor (optional)
  • Optional Supervisor deployment in management domain or workload domain
  • Optional NSX Edge Cluster deployment in management and/or workload domain
  • VCF Automation All Apps Org deployment as a Day 2 operation
  • Deploy one or many additional 3-node vSphere cluster in management domain via Day 2 operations
  • Support for provision-only mode (deploy VCF Installer and ESX hosts to allow greenfield deployment experience)
  • Custom CIDR support for Holodeck network
  • Custom VLAN support for Holodeck network
  • Custom DNS Domain for Holodeck environment
  • A Holorouter appliance (photon OS based) with built-in networking services such as DNS, DHCP, NTP, Proxy, dynamic routing (BGP), L2 switching and optional webtop (virtual desktop) capability
  • Support for VCF deployment only
  • vSAN OSA support only
  • Management Domain deployed with 4 nested hosts deployed as vSAN ready nodes including VMware Cloud Builder, VMware vCenter, VMware NSX, VMware SDDC-Manager
  • Optional Workload Domain deployed with 3 nested hosts deployed as vSAN ready nodes including VMware vCenter and VMware NSX
  • Optional NSX Edge Cluster deployment in management and/or workload domain
  • Deploy one or many additional 3-node vSphere cluster in management domain
  • Custom CIDR support for Holodeck network
  • Custom VLAN support for Holodeck network
  • Custom DNS Domain for Holodeck environment

Note: Holodeck 9 is not a VMware supported product, it is similar to a Fling.

Holodeck 9.1 supports nested VCF deployment for versions 5.2, 9.0, and 9.1. This can be deployed either on a single stand-alone ESX host or a vSphere cluster based on resource availability. Please check the Pre-requisites section

Holodeck 9.x Support Status

Holodeck 9.x is not a VMware supported product; it is similar to a Fling. It is intended for testing and training environments.

Holodeck 9.1 has been developed using PowerShell and VMware PowerCLI. We have bundled and packaged everything needed into a powershell module called Holodeck. This powershell module is provided to you as an in-built functionality within the OVA we ship called Holorouter.

Each Holodeck environment runs an identical nested configuration. A Holodeck environment can be deployed as a Single or Dual site Configuration. Separation of the environments and between sites within an environment is handled at the VMware vSphere Standard Switch (vSS) or VMware vSphere Distributed Switch (vDS) level. Each Holodeck pod is configured with a unique port group on the vSS/vDS per site. A VMware vSphere Port Group is configured on each vSS/vDS and configured as a VLAN trunk to facilitate communication. Components on the port group use VLAN tagging to isolate communications between nested VLANs. This removes the need to have physical VLANs plumbed to the ESX host to support nested labs. There is also an option to use an NSX overlay segment instead of a vSS/vDS port group if available.

Holorouter Overview

HoloRouter is an appliance that serves as the infrastructure backbone for Holodeck. It provides infrastructure services such as Layer-3 routing, Firewall, DHCP, DNS, NTP, BGP, Proxy, Job scheduling, etc. Through these services, HoloRouter connects the nested VCF environment to the external networks. It also provides inter-connectivity between different networks in the nested VCF environment. If you are not using custom VLANs for Holodeck, then for Site-a, VLANs 0, 10 through 25 and for Site-b, VLANs 40 through 58 are used. It is equipped with a built-in webtop (Desktop UI) which allows users access to HoloRouter via a GUI. Through the webtop service, users get easy GUI access to the nested VCF environment.

Scope of Services:

Core Infrastructure Services: - DNS: Local to Site-a and Site-b of nested VCF environment, acts as forwarder - DHCP: Local to Site-a and Site-b of nested VCF environment
- NTP: Local to Site-a and Site-b of nested VCF environment - L3 routing: Between VLANs of Site-a and Site-b of nested VCF environment - Firewall: Controls traffic to and from external networks and between networks in the nested VCF environment - BGP: Establishes relationship with NSX Tier-0 gateway for outbound connectivity for overlay networks - Proxy: Allows users to control outbound connectivity for the nested VCF environment

Enhanced Services (Holodeck 9.1):

Service domain is always vcf.lab

HoloRouter infrastructure services always use the vcf.lab domain regardless of any custom DNS domain configured via the -DNSDomain parameter. Only the nested VCF component FQDNs (vCenter, NSX, SDDC Manager, etc.) will use the custom domain.

  • Technitium DNS: Advanced DNS server with enhanced caching, performance, and management capabilities
    • Access: https://dns.vcf.lab | Username: admin | Password: VMware123!VMware123!
  • HashiCorp Vault: Integrated secrets management service for automated certificate provisioning and secure credential storage
    • Access: https://vault.vcf.lab | Root token: VMware123!VMware123!
  • Authentik SSO: Modern identity provider with single sign-on capabilities and SCIM support for automated user provisioning
    • Access: https://auth.vcf.lab | Username: akadmin | Password: VMware123!VMware123!
  • Certificate Authority: Internal CA for automated SSL certificate management across all HoloRouter services
    • Access: https://ca.vcf.lab
  • GitLab (when GitOps is enabled): Pre-configured with Holodeck deployment pipeline and HoloRouter registered as a runner
    • Access: https://gitlab.vcf.lab | Username: root | Password: VMware123!VMware123!
    • Container Registry: https://gitlab-registry.vcf.lab
  • Webtop: Light desktop GUI for accessing HoloRouter and the nested VCF environment
    • Access: https://webtop.vcf.lab | Username: admin | Password: VMware123!VMware123!
  • HTTPS Endpoints: All HoloRouter services use secure HTTPS endpoints via a built-in reverse proxy with automated SSL certificate management

Management & Automation: - Job scheduling: Allows users to schedule commands/scripts to be run recursively - Webtop: Allows users to access HoloRouter and nested VCF environment via a simple GUI. Accessible on port 30000 of the HoloRouter management IP. Credentials: admin / VMware123!VMware123! - Enable GitOps: Installs and configures GitLab on HoloRouter as part of OVA deployment. A GitLab repository is pre-configured with a pipeline to run Holodeck deployments, and HoloRouter is registered as a GitLab runner with the appropriate tags and parameters — so users can trigger a Holodeck deployment directly from the GitLab UI without needing to run PowerShell commands manually - PowerShell with VMware PowerCLI: Enhanced with additional modules and cmdlets for comprehensive Holodeck management - Enhanced Day 2 Operations: Comprehensive set of Day 2 operations via Update-HoloDeckInstance cmdlet - All required packages: Complete package set to deploy and operate Holodeck with enhanced validation and error handling

Concepts

  • Centralized Configuration: Holodeck 9.x has been designed around the concept of a centralized config file that acts as the source of truth for nested VCF deployments. The config file is a JSON file with a set of templates that are needed to run Holodeck. Customers are not expected to interact with the config file directly or edit it. We have built powershell cmdlets that help create, edit or import the config file as needed. The default template for config file is stored in /holodeck-runtime/templates/config.json. This config.json file is replicated and placed in /holodeck-runtime/config/<config-ID>.json when a new holodeck config is created using the cmdlet New-HoloDeckConfig.

  • Idempotency: We know that deploying an entire full stack SDDC deployment can be time consuming. We also know that this time can increase even further when performing nested deployments. We've all been in a situation where we reach towards the end of the deployment only to realize we missed something minor that causes deployment failure and we have to start all over again. To solve this challenge, we've brought in the idempotency feature in Holodeck 9.x. We store the state of the holodeck deployment on Holorouter thus allowing users to run the same command used to deploy Holodeck and pick up right where the code failed, eliminating the need to restart entire deployment or proceed manually in case of failure.

  • Automated Networking: Assigning VLANs, IP addresses, routes etc for each of your deployments can seem like a daunting task. We take this pain away in Holodeck 9 We use a default CIDR (10.1.0.0/20) and build out the entire networking including DNS mapping for each of your nested hosts and VCF components, entire routing including BGP setup for NSX Edge peering. For end users looking to deploy Holodeck in a custom CIDR, we provide the option to bring in your own CIDR of /20 size as an input parameter and we automatically use that to deploy VCF in the CIDR you provide. End users also get an option to specify their own VLANs and DNS domain for the Holodeck environment. Holodeck uses vcf.lab as the default DNS domain but users can specify a custom DNS domain during deployment.

  • Built-In PreChecks: Holodeck 9 runs a set of pre-checks when a new deployment is run to ensure everything needed is available such as all the required binaries are available in the right location or not, is the target host reachable etc.

Holodeck Networking

Let's take a look at the default VLANs used within the Holodeck Network for Site A:

image

Download the Required Software

Navigate to the Downloads Page to download Holodeck binaries.

Pre-requisites

Physical Host requirements

VCF 5.2 Single Site Dual Site
CPU 16 32
Memory 384 GB 1TB
Disk 2 TB 4TB

If deploying VCF Automation with vSAN ESA:

VCF 9.0 Single Site Dual Site
CPU 32 64
Memory 325 GB 768 GB
Disk 1.1 TB 2.5TB

If deploying VCF Automation with vSAN OSA:

VCF 9.0 Single Site Dual Site
CPU 24 48
Memory 325 GB 768 GB
Disk 1.1 TB 2.5TB
VVF 9.0 Single Site Dual Site
CPU 12 24
Memory 256 GB 512 GB
Disk 1 TB 2TB
VCF 9.1 Single Site Dual Site
CPU 48 96
Memory 650 GB 1536 GB (1.5TB)
Disk 2.2 TB 5TB
VVF 9.1 Single Site Dual Site
CPU 24 48
Memory 512 GB 1024 GB (1TB)
Disk 2 TB 4TB

VCF 9.1 Resource Validation

The resource requirements above are recommended for optimal performance. Holodeck 9.1 includes soft validation that allows deployment with lower resources, but performance may be impacted. The pre-check validation will warn if resources are below recommended levels.

Configuration requirements

  1. Ensure MTU of vDS/vSS/NSX switch is set to 9000.

  2. Create a dedicated trunk port on the vSwitch (vSS) or vDS for connecting to Holorouter. Dedicated port group ensures Holodeck does not interfere with your environment's networking. An NSX overlay trunk port group can be used instead as well.

  3. If vSS/vDS port group is used, configure security settings on the trunk port group as described below. The required settings differ between vSS and vDS — read carefully.

    vSS (Standard Switch) — Enable Promiscuous Mode:

    Security Settings for vSS Port Group
    Figure: Security Settings for vSS Port Group — Promiscuous mode: Accept

    vDS (Distributed Switch) — Use MAC Learning instead of Promiscuous Mode:

    Security Settings for vDS Port Group
    Figure: Security Settings for vDS Port Group — Promiscuous mode: Reject, MAC Learning: Enabled

    vDS: Promiscuous Mode and MAC Learning are mutually exclusive

    On a Distributed Switch, you should not enable both Promiscuous mode and MAC Learning at the same time. Use MAC Learning (enabled) with Promiscuous mode set to Reject. The required Security tab settings for vDS are:

    Setting Value
    Promiscuous mode Reject
    MAC address changes Accept
    Forged transmits Accept

    And under the Security → MAC Learning section:

    Setting Value
    Status Enabled
    Allow unicast flooding Enabled
    MAC limit 4096
    MAC limit policy Allow

  4. If NSX port group is used, ensure the type is Overlay and allow VLANs 0 to 4094 (or if using default VLANs, at a minimum VLANs 0,10-25 for Site A and 40-58 for Site-B; if using custom VLANs, VLAN 0 and custom VLAN range). Create custom segment profiles with settings as per below by navigating to Networking --> Segments tab on the left navigation bar, then click on Profiles tab on the right, click on Add segment profile and select the profiles as per below

    IP Discovery Profile in NSX
    Figure: IP Discovery Profile in NSX

    MAC Discovery Profile in NSX
    Figure: MAC Discovery Profile in NSX

    Segment Security Profile in NSX
    Figure: Segment Security Profile in NSX

    Once the profiles have been created, navigate to the overlay segment you wish to use and edit the segment and update the segment profiles association.

  5. If a vCenter is used as the target for deploying nested VCF lab, then VLANs 0, 10 through 25 and 40 through 58 (or VLAN 0 and custom VLAN range as specified by the user) need to be allowed on the physical switches to allow inter-host communication within the vSphere cluster where the nested VCF deployment will occur.

Target Host Configuration

  • Version vSphere 8.0u3 and 9.0 have been tested and are supported
  • Stand-alone non vCenter Server managed host or a vSphere cluster managed by a VMware vCenter server instance
  • Virtual Standard switch and port groups configured per guidelines
  • External/Customer networks required
  • ESX host management IP (one per host)
  • 6 CPU, 12 GB RAM and 75 GB storage for Holorouter (Internet access is optional)
  • Backing storage should be SSD/NVMe based
  • Holorouter external IP address per Holodeck Environment
  • NTP service needs to be enabled and an NTP server must be configured. If using vCenter as the target, then all hosts within the vCenter cluster must have NTP running and configured.

Licensing

Holodeck 9.x supports VCF 5.2.x, 9.0.x, and 9.1.x in "License Later" deployment mode. This mode enables all functionality for 90 days from the date of install for VCF 9.x and for 60 days for VCF 5.2.x. After that time period expires, the environment will need to be redeployed, or license must be added. Licensing is the responsibility of the end-user to ensure they procure the appropriate licenses by working with their account teams.

Offline Depot

Holodeck 9 supports both online and offline depot modes for VCF 9.x deployments. If you plan to use an offline depot (e.g., in environments with limited or no internet connectivity), you will need to set up the Offline Depot before initiating your Holodeck deployment. The offline depot provides faster download speeds, content curation, and is essential for air-gapped environments.

For detailed instructions on deploying and configuring the Offline Depot Appliance, including populating binaries, and integrating with Holodeck, please refer to the dedicated Offline Depot page.

Note

The offline depot is applicable only for VCF 9.x deployments. VCF 5.2.x deployments use Cloud Builder and do not require an offline depot.

Note

If using an existing an existing Offline depot with previous VCF 9 binaries available, ensure you use the latest manifest available on Broadcom Support Portal.

Deployment

Ensure all the pre-requistes stated earlier are completed.

Deploy Holorouter OVA

Holodeck 9 supports deployments on both stand-alone ESX hosts as well as vCenter as target. Choose the appropriate tab below to follow the instructions for your specific target to deploy Holorouter.

  1. Log in to your target ESX host web interface "https://"
  2. Right Click "Virtual Machines" and select "Create/Register VM"
  3. In the modal window select "Deploy a virtual machine from OVF or OVA file"
  4. Give the VM a name and select the Holorouter OVA you downloaded previously
  5. Select the appropriate Storage and Networking where your Holodeck instance will be deployed. You will select an (External) port group for Management and then another (Trunk) for Site A and Site B - With the default Site configurations you can effectively use the same port group for both sites (They are on discrete VLANs and subnets).
  6. Agree to the EULA
  7. On the Additional settings screen, fill in the Router Network fields and configure Extra Properties:
    • Hostname: Name for the HoloRouter VM (e.g. holorouter)
    • Management IP / CIDR / Gateway / DNS / NTP: Leave blank for DHCP, or fill in static values. The Management IP is how you will reach HoloRouter and all nested components.
    • DNS Domain: Default is site-a.vcf.lab
    • Password / Password confirm: Sets the HoloRouter admin password
    Under Extra Properties:
    • Enable SSH: Allows SSH access to HoloRouter
    • Enable UI (Webtop): Provides a light desktop GUI accessible at https://webtop.vcf.lab or http://<holorouter-ip>:30000. Credentials: admin / VMware123!VMware123!
    • Enable GitOps (enabled by default): Installs and configures GitLab on HoloRouter with a pre-loaded Holodeck deployment pipeline and HoloRouter registered as a GitLab runner. Access at https://gitlab.vcf.lab
  8. Click Finish

  1. Log in to your vCenter server https://
  2. Right click your cluster and select "Deploy OVF Template"
  3. Give the VM a name and select the Holorouter OVA you downloaded previously
  4. Select the appropriate Storage and Networking where your Holodeck instance will be deployed. You will select an (External) port group for Management and then another (Trunk) for Site A and Site B - With the default Site configurations you can effectively use the same port group for both sites (They are on discrete VLANs and subnets).
  5. On the Additional settings screen, fill in the Router Network fields and configure Extra Properties:
    • Hostname: Name for the HoloRouter VM (e.g. holorouter)
    • Management IP / CIDR / Gateway / DNS / NTP: Leave blank for DHCP, or fill in static values. The Management IP is how you will reach HoloRouter and all nested components.
    • DNS Domain: Default is site-a.vcf.lab
    • Password / Password confirm: Sets the HoloRouter admin password
    Under Extra Properties:
    • Enable SSH: Allows SSH access to HoloRouter
    • Enable UI (Webtop): Provides a light desktop GUI accessible at https://webtop.vcf.lab or http://<holorouter-ip>:30000. Credentials: admin / VMware123!VMware123!
    • Enable GitOps (enabled by default): Installs and configures GitLab on HoloRouter with a pre-loaded Holodeck deployment pipeline and HoloRouter registered as a GitLab runner. Access at https://gitlab.vcf.lab
  6. Click Finish

Accessing Holodeck Environment

Users access to the Holodeck environment is via the Holorouter. Access to Holorouter is available via two paths:

  • For UI access, open a web browser from a JumpHost or Console that has access to the external IP of Holorouter and navigate to the URL http://:30000

  • For CLI access, SSH to Holorouter using the command:

ssh root@<Holorouter IP>

Use the password that was set for Holorouter during OVA deployment.

Stage software to build host

Upload the binaries for VCF Installer/Cloud Builder and VMware ESX that were downloaded in the Pre-requisites section to the below folder on holorouter:

VCF Version Folder Path
VCF 9.1.0.0 /holodeck-runtime/bin/9.1.0.0/
VCF 9.0.2.0 /holodeck-runtime/bin/9.0.2.0/
VCF 9.0.1.0 /holodeck-runtime/bin/9.0.1.0/
VCF 9.0.0.0 /holodeck-runtime/bin/9.0.0.0/
VCF 5.2.4 /holodeck-runtime/bin/5.2.4/
VCF 5.2.3 /holodeck-runtime/bin/5.2.3/
VCF 5.2.2 /holodeck-runtime/bin/5.2.2/
VCF 5.2.1 /holodeck-runtime/bin/5.2.1/
VCF 5.2 /holodeck-runtime/bin/5.2/

The files can be downloaded by accessing the Broadcom Support Portal within the webtop UI (assuming proper entitlement is available for end-user)

Another option is to download the files locally and use scp to copy the files using the below command:

For VCF 9.1.0.0:

scp /<local-path>/<ESX ISO File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/9.1.0.0/
scp /<local-path>/<VCF Installer OVA File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/9.1.0.0/

For VCF 9.0.2.0:

scp /<local-path>/<ESX ISO File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/9.0.2.0/
scp /<local-path>/<VCF Installer OVA File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/9.0.2.0/

For VCF 9.0.1.0:

scp /<local-path>/<ESX ISO File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/9.0.1.0/
scp /<local-path>/<VCF Installer OVA File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/9.0.1.0/

For VCF 9.0.0.0:

scp /<local-path>/<ESX ISO File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/9.0.0.0/
scp /<local-path>/<VCF Installer OVA File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/9.0.0.0/

Note

  • Holodeck 9.1 supports VCF Installer 9.1.0.0 for deploying VCF 9.1.0.0 environments.
  • Holodeck recommends VCF Installer 9.0.2.0 for deploying VCF 9.0.0.0, VCF 9.0.1.0 and VCF 9.0.2.0.
  • VCF Installer 9.0.0.0 is no longer supported on Holodeck for nested VCF deployments.

For VCF 5.2.4:

scp /<local-path>/<ESX ISO File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/5.2.4/
scp /<local-path>/<VCF Installer OVA File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/5.2.4/

For VCF 5.2.3:

scp /<local-path>/<ESX ISO File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/5.2.3/
scp /<local-path>/<VCF Installer OVA File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/5.2.3/

For VCF 5.2.2:

scp /<local-path>/<ESX ISO File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/5.2.2/
scp /<local-path>/<VCF Installer OVA File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/5.2.2/

For VCF 5.2.1:

scp /<local-path>/<ESX ISO File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/5.2.1/
scp /<local-path>/<VCF Installer OVA File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/5.2.1/

For VCF 5.2:

scp /<local-path>/<ESX ISO File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/5.2/
scp /<local-path>/<VCF Installer OVA File Name> root@<Holorouter-IP>:/holodeck-runtime/bin/5.2/

Run Holodeck deployment

Once logged in to Holorouter via SSH, run the following commands:

Open PowerShell:

pwsh

Use the command below to create a new Holodeck config. This command creates a config file specific for your deployment with a unique config ID and loads the config file into the $config variable.

New-HoloDeckConfig -Description <Description> -TargetHost <Target vCenter/ESX IP/FQDN> -Username <username> -Password <password>

image

Config to Deployment: 1:1 Mapping

Each Holodeck configuration file is mapped to a single deployment. Always create a new config for each new deployment. Do not re-use the same config for multiple deployments as it may lead to state conflicts and unpredictable behavior.

Dual-Site Configuration (Holodeck 9.1)

Starting with Holodeck 9.1, New-HoloDeckConfig automatically creates two configuration files for dual-site deployments:

  • Site A Configuration: Automatically loaded into the PowerShell session by default
  • Site B Configuration: Created but not loaded automatically

To switch to the Site B configuration, use Import-HoloDeckConfig -ConfigId <id> -Site b

Multiple config files can be created by running the above command multiple times for different use-cases such as 1 config for VCF 5.2 deployment and another for VCF 9.0 deployment.

To check which config is currently loaded in your powershell session, run the below command and check the config ID or description:

$config

image

Note that $config is specific to a powershell session. If you exit powershell and open a new session, you will need to import the config using:

Get-HoloDeckConfig

The above command gives a list of config files available. Note the config ID for your specific deployment to use in the below command. You must use the -Site parameter to specify which site configuration to load:

Import-HoloDeckConfig -ConfigId <String> -Site a
Import-HoloDeckConfig -ConfigId <String> -Site b

image

The same procedure can be followed if you wish to switch from one config file to another as well. Holodeck 9.1 automatically creates both Site A and Site B configurations, and Site A is loaded by default. For single-site deployments, you will use the Site A configuration (-Site a).

Deploy a Holodeck instance using the New-HoloDeckInstance command. This command can be operated in 4 different ways as shown below:

image

If you notice closely, some of the parameters have a square bracket around them while others do not. The ones that have square brackets around them are optional parameters. With this information, let's look at each option in the Syntax section of the above image.

VVF Deployment

New-HoloDeckInstance -Version <String> -InstanceID <String> [-CIDR <String[]>] [-vSANMode <String>] [-LogLevel <String>] [-ProvisionOnly] [-VLANRangeStart <Int32[]>] [-DNSDomain <String>] -VVF [-Site <String>] [-DepotType <String>] [-DeveloperMode] [<CommonParameters>]

In the first option, we see that -VVF, -Version and -InstanceID are mandatory, showcasing this syntax is used for VVF deployment.

Note: VVF deployment is supported only when -Version is selected as "9.0.0.0" and beyond (including "9.1.0.0"). Using -Version "5.2" with -VVF yields no result.

Management-Domain Only Deployment

New-HoloDeckInstance -Version <String> -InstanceID <String> -ManagementOnly [-CIDR <String[]>] [-vSANMode <String>] [-NsxEdgeClusterMgmtDomain] [-VnaClusterMgmtDomain] [-DeployVcfAutomation] [-DeploySupervisorMgmtDomain <String>] [-LogLevel <String>] [-ProvisionOnly] [-VLANRangeStart <Int32[]>] [-DNSDomain <String>] [-Site <String>] [-DepotType <String>] [-DeveloperMode] [<CommonParameters>]

In the second option, we see that -ManagementOnly, -Version and -InstanceID are mandatory, showcasing this syntax is used to deploy a nested VCF deployment with management domain only.

Parameter Type Required Description Options Default Value
Version String Mandatory Provide VCF version "9.1.0.0", "9.0.2.0", "9.0.1.0", "9.0.0.0", "5.2.4", "5.2.3", "5.2.2", "5.2.1" or "5.2"
InstanceID String Mandatory Instance ID used as a prefix before all nested VMs deployed as part of Holodeck to uniquely identify the instance. String
CIDR Array of Strings Optional VCF instance is deployed by default in the 10.1.0.0/20 CIDR for Site a and 10.2.0.0/20 for Site b. If you wish to use a custom CIDR, provide a CIDR of /20 size. For single site (site a) deployment, specify only a single CIDR. For site b deployment in a dual site scenario, specify an array of CIDRs using an array [n,m] where n and m are the CIDRs for Site a and Site b respectively. String of format: ["10.3.0.0/20","10.4.0.0/20"] ["10.1.0.0/20","10.2.0.0/20"]
vSANMode String Optional Support for both vSAN Express Storage Architecture (ESA) and Original Storage Architecture (OSA) "ESA" or "OSA" "OSA"
ManagementOnly Switch Mandatory Deploys a VCF instance with Management domain only NA
NsxEdgeClusterMgmtDomain Switch Optional Deploys an NSX Edge Cluster in Management domain (AVN included if deploying VCF 5.2) NA
VnaClusterMgmtDomain Switch Optional NEW in 9.1: Deploys a Virtual Network Appliance (VNA) cluster in Management domain for distributed networking NA
DeployVcfAutomation Switch Optional Deploys VCF Automation. This is applicable only if -Version is set to "9.0.0.0" and beyond (including "9.1.0.0"). VCF Automation is not deployed by default unless this switch is used. NA
DeploySupervisorMgmtDomain String Optional ENHANCED in 9.1: Deploys Supervisor in management domain with networking mode selection. Applicable only for VCF 9.0.0.0 and beyond (including VCF 9.1.0.0). "Centralized" or "Distributed"
ProvisionOnly Switch Optional Deploys nested ESX hosts and VCF Installer/Cloud Builder and provides JSON API specs for performing VCF deployment manually NA
VLANRangeStart Array of Integers Optional VCF instance is deployed by default with VLANs 0, 10 through 25 for Site a and 40 through 58 for Site b. If you wish to use a custom VLAN range, provide the start of the custom VLAN range using this paramater. You can specify only an integerfor a single site (site a) deployment. For site b (in a dual site deployment scenario), you should specify an array [n,m] where n and m are the VLAN start range for Site a and Site b respectively. The VLAN specified for Site a should have at least 16 consecutive valid VLAN IDs and for site b, it should have at least 19 consecutive valid VLAN IDs. Integer of format: [100,200] [10,40]
DNSDomain String Optional VCF instance is deployed by default with DNS domain vcf.lab. Users can specify a custom DNS domain using this parameter. Note: HoloRouter infrastructure services (Vault, Authentik, GitLab, etc.) always remain on vcf.lab regardless of this setting. String of format: demo.lab vcf.lab
Site String Optional Deploy site a or b in a VCF Instance "a" or "b" "a"
DepotType String Optional Applicable for -Version 9.0.0.0 and beyond (including 9.1.0.0) only. Choose whether VCF Installer should use the online or offline depot to download VCF 9 components. "Online" or "Offline" "Online"
LogLevel String Optional Set the log level you wish to view One of "INFO", "DEBUG", "SUCCESS", "WARN", "ERROR" "INFO"
DeveloperMode Switch Optional Enables automated deployments using environment variables. NA

Full Stack Deployment

New-HoloDeckInstance -Version <String> -InstanceID <String> [-CIDR <String[]>] [-vSANMode <String>] [-WorkloadDomainType <String>] [-NsxEdgeClusterMgmtDomain] [-NsxEdgeClusterWkldDomain] [-VnaClusterMgmtDomain] [-VnaClusterWkldDomain] [-DeployVcfAutomation] [-DeploySupervisorWldDomain <String>] [-DeploySupervisorMgmtDomain <String>] [-LogLevel <String>] [-ProvisionOnly] [-VLANRangeStart <Int32[]>] [-DNSDomain <String>] [-Site <String>] [-DepotType <String>] [-DeveloperMode] [<CommonParameters>]

In the third option, we see that -Version and -InstanceID are mandatory, and it also has an optional parameter called -WorkloadDomainType showcasing this syntax is used for deploying a full stack nested VCF deployment. -WorkloadDomainType is optional as it already has a default value set.

Parameter Type Required Description Options Default Value
Version String Mandatory Provide VCF version "9.1.0.0", "9.0.2.0", "9.0.1.0", "9.0.0.0", "5.2.4", "5.2.3", "5.2.2", "5.2.1" or "5.2"
InstanceID String Mandatory Instance ID used as a prefix before all nested VMs deployed as part of Holodeck to uniquely identify the instance. String
CIDR String Optional VCF instance is deployed by default in the 10.1.0.0/20 CIDR for Site a and 10.2.0.0/20 for Site b. If you wish to use a custom CIDR, provide a CIDR of /20 size. For single site (site a) deployment, specify only a single CIDR. For site b deployment in a dual site scenario, specify an array of CIDRs using an array [n,m] where n and m are the CIDRs for Site a and Site b respectively. String of format: ["10.3.0.0/20","10.4.0.0/20"] ["10.1.0.0/20","10.2.0.0/20"]
vSANMode String Optional Support for both vSAN Express Storage Architecture (ESA) and Original Storage Architecture (OSA) "ESA" or "OSA" "OSA"
WorkloadDomainType String Optional Choose whether you want to share the management domain SSO with workload domain or use a separate SSO (wld.sso). "SharedSSO" or "IsolatedSSO" ""
NsxEdgeClusterMgmtDomain Switch Optional Deploys an NSX Edge Cluster in Management domain (AVN included if deploying VCF 5.2) NA
NsxEdgeClusterWkldDomain Switch Optional Deploys an NSX Edge Cluster in Workload domain (AVN included if deploying VCF 5.2) NA
VnaClusterMgmtDomain Switch Optional NEW in 9.1: Deploys a Virtual Network Appliance (VNA) cluster in Management domain for distributed networking NA
VnaClusterWkldDomain Switch Optional NEW in 9.1: Deploys a Virtual Network Appliance (VNA) cluster in Workload domain for distributed networking NA
DeployVcfAutomation Switch Optional Deploys VCF Automation. This is applicable only if -Version is set to "9.0.0.0" and beyond (including "9.1.0.0"). VCF Automation is not deployed by default unless this switch is used. NA
DeploySupervisorWldDomain String Optional ENHANCED in 9.1: Deploys Supervisor in workload domain with networking mode selection. Applicable only for VCF 9.0.0.0 and beyond (including VCF 9.1.0.0). "Centralized" or "Distributed"
DeploySupervisorMgmtDomain String Optional ENHANCED in 9.1: Deploys Supervisor in management domain with networking mode selection. Applicable only for VCF 9.0.0.0 and beyond (including VCF 9.1.0.0). "Centralized" or "Distributed"
ProvisionOnly Switch Optional Deploys nested ESX hosts and VCF Installer/Cloud Builder and provides JSON API specs for performing VCF deployment manually NA
VLANRangeStart Array of Integers Optional VCF instance is deployed by default with VLANs 0, 10 through 25 for Site a and 40 through 58 for Site b. If you wish to use a custom VLAN range, provide the start of the custom VLAN range using this paramater. You can specify only an integerfor a single site (site a) deployment. For site b (in a dual site deployment scenario), you should specify an array [n,m] where n and m are the VLAN start range for Site a and Site b respectively. The VLAN specified for Site a should have at least 16 consecutive valid VLAN IDs and for site b, it should have at least 19 consecutive valid VLAN IDs. Integer of format: [100,200] [10,40]
DNSDomain String Optional VCF instance is deployed by default with DNS domain vcf.lab. Users can specify a custom DNS domain using this parameter. Note: HoloRouter infrastructure services (Vault, Authentik, GitLab, etc.) always remain on vcf.lab regardless of this setting. String of format: demo.lab vcf.lab
Site String Optional Deploy site a or b in a VCF Instance "a" or "b" "a"
DepotType String Optional Applicable for -Version 9.0.0.0 and beyond (including 9.1.0.0) only. Choose whether VCF Installer should use the online or offline depot to download VCF 9 components. "Online" or "Offline" "Online"
LogLevel String Optional Set the log level you wish to view One of "INFO", "DEBUG", "SUCCESS", "WARN", "ERROR" "INFO"
DeveloperMode Switch Optional Enables automated deployments using environment variables. NA

Dual Site Deployment

For dual site deployments with default CIDRs and VLAN ranges: 

New-HoloDeckNetworkConfig -Site a -MasterCIDR 10.1.0.0/20
New-HoloDeckNetworkConfig -Site b -MasterCIDR 10.2.0.0/20
Set-HoloRouter -dualsite
New-HoloDeckInstance -Site a [Additional Parameters]

Open a new tab in powershell, import the config and run 

New-HoloDeckInstance -Site b [Additional Parameters]

For dual site deployments with custom CIDRs and VLAN ranges: 

New-HoloDeckNetworkConfig -Site a -MasterCIDR <site-a-cidr> -VLANRangeStart <site-a-vlanrangestart>
New-HoloDeckNetworkConfig -Site b -MasterCIDR <site-b-cidr> -VLANRangeStart <site-b-vlanrangestart>
Set-HoloRouter -dualsite
New-HoloDeckInstance -Site a -CIDR <site-a-cidr> -VLANRangeStart <site-a-vlanrangestart> [Additional Parameters]

Open a new tab in powershell, import the config and run 

New-HoloDeckInstance -Site b -CIDR <site-a-cidr>,<site-b-cidr> -VLANRangeStart <site-a-vlanrangestart>,<site-b-vlanrangestart> [Additional Parameters]

Note

If you provide custom CIDRs please ensure it is a /20 in size. If custom CIDR and VLAN ranges are used in New-HoloDeckNetworkConfig, then the same custom CIDRs and start of custom VLAN ranges need to be furnished in New-HoloDeckInstance command to avoid the custom CIDRs or VLANs being overwritten by the default values.

Developer Mode

The -DeveloperMode Parameter allows you to automate deployments by defining all interactive inputs as environment variables. To run this, open a powershell session on Holorouter and define the following variables:

  • Online Depot Configuration

    For online depot deployments:

    $env:brcm_build_token = "build"
$env:enable_proxy = "y" or "n"

    If proxy is enabled, set the following:

    $env:proxy_protocol = "http" or "https"
$env:proxy_ip = "<proxy_ip_address>"
$env:proxy_port = "<proxy_port>"
$env:enable_proxy_auth = "y" or "n"

    If proxy authentication is enabled, set the following:

    $env:proxy_username = "<proxy_username>"
$env:proxy_password = "<proxy_password>"

  • Offline Depot Configuration

    For offline depot deployments, define the following environment variables:

    $env:offline_depot_ip = "<offline_depot_ip_address>"
$env:offline_depot_port = "<offline_depot_port>"
$env:offline_depot_username = "<offline_depot_username>"
$env:offline_depot_password = "<offline_depot_password>"
$env:offline_depot_protocol = "http" or "https"

  • Datastore and Network Port Group details:

    $env:datastore_name = "<datastore_name>"
$env:trunk_port_group_name = "<trunk_port_group_name>"

  • If vCenter is the target, set the following:

    $env:cluster_name = "<cluster_name>"
$env:dc_name = "<datacenter_name>"

After setting the environment variables, run the New-HoloDeckConfig and New-HoloDeckInstance command as you would in a manual deployment with the parameters you require and the user inputs will automatically be captured from the environment variables.

For Dual Site, open 2 powershell sessions and provide the required values to the same variables in both the sessions.

Approx times for tested workflows (for 9.0.0.0):

Parameters Time Notes
-ManagementOnly 4-5 hours Just 4 hosts for management domain
-NsxEdgeClusterMgmtDomain 5-6 hours 4 hosts without and 2 node Edge Cluster
-DeployVCFAuto -DeploySupervisorWldDomain 12+ 4 hosts management with VCF Automation, 3 hosts WLD, Edge Cluster and Supervisor

Please note that the time mentioned above is only an indication as the actual time taken depends on multiple factors such as the physical environment, networking connectivity etc.

During Deployment

You may see "errors" during the deployment phase, if they are not displayed in RED text and exit the script, they are handled and you shouldn't need to worry about them.

Online Depot method

image

This is an interactive section during the pre-checks where you select the desired datastore to use for Holodeck deployment:

image

Choose your desired trunk port group to deploy the nested VMs (ESX and VCF Installer/Cloud Builder) on:

image

Pre-Checks are completed. If going through the online route, you need to provide the broadcom support site token:

image

Networking setup completed on Holorouter:

image

Deployment initiated:

image

Nested ESX hosts getting built:

image

VCF Installer being deployed:

image

VCF bundles being downloaded:

image

Management Domain deployment initiated through VCF Installer:

image

Management Domain deployment completed and Workload Domain deployment initiated:

image

Deployment completed successfully:

image

Offline Depot method

For setting up the offline depot, check out the Offline Depot Page.

The procedure is similar to online depot except instead of passing the build token, customer needs to provide the details of the offline depot interactively:

image

Post Deployment

Once Holodeck is deployed, you can access the VCF components on your browser, assuming you have opted for default DNS domain (local based on your networking setup or webtop):

Appliance FQDN Username Password
Management Domain
VCF Installer or Cloud Builder https://vcfinstaller-a.site-a.vcf.lab admin@local for VCF Installer admin for Cloud Builder VMware123!VMware123!
VCF Operations https://ops-a.site-a.vcf.lab/ admin or admin@local VMware123!VMware123!
VCF Automation https://auto-a.site-a.vcf.lab/ Organization: system admin VMware123!VMware123!
ESX https://esx-01a.site-a.vcf.lab https://esx-02a.site-a.vcf.lab https://esx-03a.site-a.vcf.lab https://esx-04a.site-a.vcf.lab root VMware123!VMware123!
Management vCenter https://vc-mgmt-a.site-a.vcf.lab/ administrator@vsphere.local VMware123!VMware123!
SDDC-Manager https://sddcmanager-a.site-a.vcf.lab/ administrator@vsphere.local VMware123!VMware123!
Management NSX https://nsx-mgmt-a.site-a.vcf.lab admin VMware123!VMware123!
Workload Domain
Workload vCenter https://vc-wld01-a.site-a.vcf.lab/ administrator@wld.sso if Isolated SSO enabled administrator@vsphere.local otherwise VMware123!VMware123!
Workload NSX https://nsx-wld01-a.site-a.vcf.lab/ admin VMware123!VMware123!
ESX https://esx-05a.site-a.vcf.lab https://esx-06a.site-a.vcf.lab https://esx-07a.site-a.vcf.lab root VMware123!VMware123!
Infrastructure
HashiCorp Vault https://vault.vcf.lab (or https://holorouter-ip:8200) Root token (no username)
Authentik SSO https://auth.vcf.lab (or https://holorouter-ip:9443) akadmin
Technitium DNS https://dns.vcf.lab (or https://holorouter-ip:5380) admin
Certificate Authority https://ca.vcf.lab —
GitLab https://gitlab.vcf.lab root
GitLab Registry https://gitlab-registry.vcf.lab root
Webtop https://webtop.vcf.lab (or http://holorouter-ip:30000) admin

The above table has been generated for Site A. If you have deployed Site B, replace "site-a" in the FQDN with "site-b". For example, Management vCenter for Site A is https://vc-mgmt-a.site-a.vcf.lab/ and Management vCenter for Site B is https://vc-mgmt-a.site-b.vcf.lab/

Service Access Notes

  • HoloRouter service FQDNs are always on vcf.lab, even if you deployed with a custom -DNSDomain. The *.vcf.lab domain is static for all HoloRouter infrastructure services. Only the nested VCF component FQDNs (vCenter, NSX, SDDC Manager, etc.) reflect the custom domain.
  • FQDN-based access (e.g. vault.vcf.lab, auth.vcf.lab) requires your console to use the HoloRouter as its DNS server so that these names resolve correctly.
  • All HoloRouter infrastructure services are served over HTTPS via a built-in reverse proxy. The individual services run on HTTP internally but are exposed securely via HTTPS at the FQDNs above.
  • Webtop can also be accessed directly over HTTP at http://holorouter-ip:30000 (bypassing the reverse proxy).
  • GitLab and GitLab Registry are only present if Enable GitOps was enabled during OVA deployment (it is enabled by default).
  • DNS Server IP for your console: Use the external management IP of the HoloRouter as your DNS server if your console is on a different network than the Holodeck networks. If your console is on one of the Holodeck networks (e.g. 10.1.x.x), use the gateway IP of that network instead.

Day 2 Operations

Use the Update-HoloDeckInstance cmdlet to perform Day 2 operations on a Holodeck instance after it has been deployed successfully. Each operation uses specific parameter sets that cannot be combined in a single invocation.

Deploy Additional Cluster

Deploys an additional 3-node vSphere cluster in the Management or Workload domain.

Update-HoloDeckInstance -Site a -AdditionalCluster -VIDomain Management

Update-HoloDeckInstance -Site a -AdditionalCluster -VIDomain Workload
Parameter Type Required Description Options
Site String Mandatory Site identifier "a" or "b"
AdditionalCluster Switch Mandatory Triggers additional cluster deployment NA
VIDomain String Mandatory Target domain for the cluster "Management" or "Workload"
Deploy VCF Automation All Apps Org

Creates a VCF Automation All Apps Org in the specified domain. Requires VCF Automation to already be deployed in the instance. This command sets up the required constructs for creating an organization such as region, region quota, IP space etc.

Update-HoloDeckInstance -Site a -AddVcfAutomationAllAppsOrg -VIDomain Management
Parameter Type Required Description Options
Site String Mandatory Site identifier "a" or "b"
AddVcfAutomationAllAppsOrg Switch Mandatory Triggers All Apps Org creation in VCF Automation NA
VIDomain String Mandatory Target domain "Management" or "Workload"
Version String Optional VCF version "9.0.0.0", "9.0.1.0", "9.0.2.0", "9.1.0.0"
Deploy Supervisor

Deploys Supervisor in management or workload domain. For VCF 9.1.0.0, supports both Centralized (Edge) and Distributed (VNA) deployment modes.

Update-HoloDeckInstance -Site a -DeploySupervisor -VIDomain Management

Update-HoloDeckInstance -Site a -DeploySupervisor -VIDomain Workload -SupervisorDeploymentMode Distributed
Parameter Type Required Description Options
Site String Mandatory Site identifier "a" or "b"
DeploySupervisor Switch Mandatory Triggers Supervisor deployment NA
VIDomain String Mandatory Target domain for Supervisor "Management" or "Workload"
SupervisorDeploymentMode String Optional Deployment mode (VCF 9.1.0.0+ only) "Centralized" or "Distributed"
Deploy VCF Automation

Deploys VCF Automation as a Day 2 operation via VCF Operations Manager.

Update-HoloDeckInstance -Site a -DeployVcfAutomation
Parameter Type Required Description Options
Site String Mandatory Site identifier "a" or "b"
DeployVcfAutomation Switch Mandatory Triggers VCF Automation deployment NA
Deploy New Hosts

Deploys new nested ESX hosts using custom specifications.

Update-HoloDeckInstance -Site a -DeployNewHosts -CPU 12 -MemoryInGb 96 -Nodes 4 -vSANMode ESA
Parameter Type Required Description Options
Site String Mandatory Site identifier "a" or "b"
DeployNewHosts Switch Mandatory Triggers new ESXi host deployment NA
CPU Integer Mandatory vCPU count for ESXi hosts Number
MemoryInGb Integer Mandatory Memory in GB for ESXi hosts Number
Nodes Integer Optional Number of hosts to deploy Number
vSANMode String Optional vSAN storage architecture "OSA" or "ESA"
VIDomain String Optional Target domain "Management", "Workload", "Unknown"
DiskSizeInGB Array Optional Custom disk sizes (max 3) Array of numbers

Note

Each Day 2 operation uses separate parameter sets and cannot be combined in a single invocation. Run separate commands for each operation.

Holodeck 9.1 Enhancements

  • SupervisorDeploymentMode: VCF 9.1.0.0 supports both "Centralized" (NSX Edge) and "Distributed" (VNA) modes
  • Enhanced Compatibility: All operations work with VCF 9.1.0.0
  • VNA Support: Virtual Network Appliance clusters supported for distributed Supervisor deployments

How To

Start and Stop Holodeck Instance

There may be situations where you have already deployed Holodeck but need the resources for another operation. In that case, we provide cmdlets to power off Holodeck and power it back on as well.

For powering off Holodeck:

Stop-HoloDeckInstance [-InstanceID] <string> [-Force]

Stop-HoloDeckInstance asks for confirmation which can be bypassed by using the -Force parameter.

image

For powering on Holodeck:

Start-HoloDeckInstance [-InstanceID] <string> [-Force]

image

Create new nested ESX hosts

You can dynamically add new ESX hosts to an existing site using the New-HoloDeckESXiNodes cmdlet. These hosts can be used for additional clusters or expanding existing clusters.

New-HoloDeckESXiNodes -Nodes <No. of Nodes> -CPU <No. of vCPU> -MemoryInGb <Memory in GB> -Site <'a' or 'b'> -vSANMode <'ESA' or 'OSA'>

image

Remove nested VCF Instance

To remove a HoloDeck Instance, run:

Remove-HoloDeckInstance [-ResetHoloRouter]

Remove-HoloDeckInstance will delete al the nested ESX hosts and VCF Installer/Cloud Builder VM associated to a specific instance.

-ResetHoloRouter will remove the networking configuration setup for the nested VCF instance. When you run New-HoloDeckInstance, the networking is configured again. This involves an automatic reboot of the Holorouter.

Get subnets in Holodeck

You can list all the subnets that have been configured or reserved for HoloDeck. You can also get information about specific subnets by specifying the name, VLAN ID, Subnet range, and Gateway IP.

Get-HoloDeckSubnet [-Name <string>] [-vlanID <string>] [-Subnet <string>] [-Gateway <string>] [-Site <string>] [<CommonParameters>]

For e.g.:
For Site 'a':
Get-HoloDeckSubnet -Site a | ft -AutoSize

For Site 'b':
Get-HoloDeckSubnet -Site b | ft -AutoSize

Get-HoloDeckSubnet -Site a -Name Untagged-HOL

Get-HoloDeckSubnet -Site b -vlanID 50

Get-HoloDeckSubnet -Site a -Gateway 10.1.1.1

Get-HoloDeckSubnet -Site a -Subnet 10.1.2.0/25

image

Get appliance details

You can list all the IP-Hostname entries generated by the Network Manager for HoloDeck. You can also get information about specific IP-Hostname mappings by specifying the IP, hostname, and FQDN.

Get-HoloDeckAppNetwork [-Hostname <string>] [-IP <string>] [-FQDN <string>] [-Site <string>] [<CommonParameters>]

For e.g.:
For Site 'a':
Get-HoloDeckAppNetwork -Site a

For Site 'b':
Get-HoloDeckAppNetwork -Site b

Get-HoloDeckAppNetwork -Site a -Hostname router

Get-HoloDeckAppNetwork -Site a -IP 10.1.1.10

Get-HoloDeckAppNetwork -Site a -FQDN esx-01a.site-a.vcf.lab

image

Get BGP configuration

You can list the BGP configuration generated by the Network Manager for HoloDeck. 

Get-HoloDeckBGPConfig [-Site <string>] [<CommonParameters>]

For e.g.:
For Site 'a':
Get-HoloDeckBGPConfig -Site a

For Site 'b':
Get-HoloDeckBGPConfig -Site b

image

Get DNS entries

You can list all the DNS entries configured in the DNS service in HoloRouter. You can also get information about a specific DNS entry by specifying its IP or FQDN. 

Get-HoloDeckDNSConfig [-IP <string>] [-FQDN <string>] [<CommonParameters>]

For e.g.:
Get-HoloDeckDNSConfig

Get-HoloDeckDNSConfig -IP 10.1.1.1

Get-HoloDeckDNSConfig -FQDN esx-02a.site-a.vcf.lab

image

Add or Update DNS entries

You can configure additional DNS entries to the DNS service in HoloRouter. To do that, use the Set-HoloDeckDNSConfig cmdlet. Note that you must specify the DNS entry in single quotes ('').

Set-HoloDeckDNSConfig -DNSRecord <string> [<CommonParameters>]

For e.g., to create a DNS entry for '10.1.1.201 harbor.site-a.vcf.lab', you would run -
Set-HoloDeckDNSConfig -DNSRecord '10.1.1.201 harbor.site-a.vcf.lab'

image

You can also replace the DNS entries existing in the DNS service in HoloRouter. You will still use the Set-HoloDeckDNSConfig but specify different parameters. Note that the DNS entries to be searched and replaced must be specified in single quotes ('').

Set-HoloDeckDNSConfig -SearchDNSRecord <string> -ReplaceDNSRecord <string> -Update [<CommonParameters>]

For e.g., to replace the DNS entry '10.1.1.201 harbor.site-a.vcf.lab' with '10.1.1.210 harbor.site-a.vcf.lab', you would run -
Set-HoloDeckDNSConfig -SearchDNSRecord '10.1.1.201 harbor.site-a.vcf.lab' -ReplaceDNSRecord '10.1.1.210 harbor.site-a.vcf.lab' -Update

image

Remove DNS entries

You can remove the DNS entries from the DNS service in HoloRouter. To do that, use Remove-HoloDeckDNSConfig cmdlet. You must specify the DNS entry in single quotes ('').

Remove-HoloDeckDNSConfig -DNSRecord <string>  [<CommonParameters>]

For e.g., to remove the DNS entry '10.1.1.210 harbor.site-a.vcf.lab', you would run -
Remove-HoloDeckDNSConfig -DNSRecord '10.1.1.210 harbor.site-a.vcf.lab'

image

Migrate Holorouter 9.0/9.0.1 to 9.0.2

Please follow the steps specified in the flowchart below to deploy and use Holorouter 9.0.2 in an existing Holodeck 9.0/9.0.1 instance.

image

Troubleshooting

Refer to the Troubleshooting section on the FAQ page for more details.