← Back to posts
Networking

Nexus Dashboard 4.2 on VMware ESX: Prerequisites, Node Types & Sizing

Before You Deploy Anything

Deploying Nexus Dashboard (ND) 4.2 in VMware ESX is straightforward — if you do the prerequisites right. Skip them and you’ll be rebuilding the cluster. This post covers everything you need locked down before you touch vCenter or ESXi.

Source: Cisco Nexus Dashboard Deployment and Upgrade Guide, Release 4.2.x


App Node vs Data Node — Pick the Right Profile

Every ND VM is deployed using one of two OVA profiles. This is one of the most important decisions you’ll make before deployment:

RequirementApp NodeData Node
vCPUs16 vCPUs32 vCPUs
CPU Reservation17,600 MHz minimum35,200 MHz minimum
RAM64 GB (physically reserved)128 GB (physically reserved)
Data Volume Storage500 GB HDD or SSD3 TB SSD
Boot Volume50 GB50 GB
Storage TypeHDD or SSD (feature dependent)SSD — Mixed Use/Application

App nodes cover most Nexus Dashboard use cases and are appropriate for the majority of deployments. Data nodes are required for specific features that need higher throughput and compute — check the Nexus Dashboard Capacity Planning tool to confirm which profile your deployment requires before ordering hardware.

For larger-scale deployments requiring secondary nodes, all nodes (primary and secondary) can use the App node OVA profile.


Data Node Storage Requirements — Non-Negotiable

If you’re deploying Data nodes, storage performance is critical. The guide specifies minimum IOPS that must be sustained, not just burst:

  • 4K Random Read IOPS: 93,000
  • 4K Random Write IOPS: 31,000
  • I/O Latency: 20ms or less
  • SSD type: Mixed Use/Application — NOT Read-Optimized
  • Attachment: Direct to datastore, or JBOD mode if using a RAID HBA

The Cisco guide does not explicitly ban HDD for Data nodes, but the performance requirements make it effectively impossible in practice. A standard enterprise HDD typically delivers around 200 IOPS — far short of the 93,000 read / 31,000 write IOPS minimum. Any storage that cannot sustain those numbers will result in performance degradation and cluster instability, so SSD is the only realistic option.

For App nodes, some features require SSD while others tolerate HDD. Consult the capacity planning tool for your specific services.


ESXi and vCenter Version Compatibility

Supported versions for both App and Data node deployments:

VMware ESXi:

  • 7.0, 7.0.1, 7.0.2, 7.0.3
  • 8.0, 8.0.2, 8.0.3

VMware vCenter (if deploying via vCenter):

  • 7.0.1, 7.0.2, 7.0.3
  • 8.0, 8.0.2, 8.0.3

Confirm your ESXi CPU family supports the AVX instruction set — this is required for ND VMs. Most modern Intel/AMD server CPUs support AVX, but verify before deployment, especially on older hardware.


Critical Restrictions — Read These Before Proceeding

These are the gotchas that catch engineers off-guard. Every one of these will cause deployment problems or cluster instability if ignored:

❌ vMotion is Not Supported

VMware vMotion must NOT be used for Nexus Dashboard cluster nodes. Do not allow vMotion migrations of ND VMs — this will break the cluster.

❌ DRS Must Be Disabled Per-VM

VMware Distributed Resource Scheduler (DRS) is not supported for ND nodes. If DRS is enabled at the ESXi cluster level, you must explicitly disable it for each Nexus Dashboard VM during deployment. There’s a checkbox in the storage screen for this — don’t skip it.

❌ No Snapshots of Running VMs

VMware snapshots are only supported when ND VMs are powered off, and must be performed on all VMs in the cluster simultaneously. Snapshots of powered-on ND VMs are not supported.

❌ No Nested Virtualization

Deploying ND on a VM that is itself running on a virtual hypervisor (e.g., KVM on ESXi) is not a supported configuration. Use bare-metal ESXi hosts only.

❌ No Content Library Deployment

Deploying via VMware content library is not supported. Use a local OVA file or hosted URL instead.

✅ Disable VMware Tools Time Synchronization

After deploying each VM, you must disable the VMware Tools periodic time synchronization option. ND manages its own time via NTP — let the VMware Tools sync override it and you’ll have cluster instability.


VLAN Configuration for Data Interfaces

If you plan to configure a VLAN ID for the cluster’s data interfaces, you must enable VLAN 4095 on the data interface port group in vCenter for Virtual Guest VLAN Tagging (VGT) mode.

Why? When you set an explicit VLAN tag on a port group in vSwitch and attach it to an ND VM’s VNIC, the vSwitch strips the 802.1Q tag before delivering it to the VM — but ND expects that tag. VLAN 4095 allows all VLANs to pass through so ND receives the tagged frames it expects.

For most deployments where you don’t specify a VLAN ID, this isn’t needed.


Spread Nodes Across Physical Hosts

Cisco recommends deploying each Nexus Dashboard node on a different ESXi host. This is a high availability best practice — if one host fails, you lose one node, not the entire cluster. A 3-node ND cluster on a single ESXi host provides zero hardware redundancy.


Pre-Deployment Checklist

Before you start the OVA deployment:

  • Confirmed node profile (App or Data) using capacity planning tool
  • Verified ESXi version compatibility (7.0.x or 8.0.x)
  • Confirmed CPU supports AVX instruction set
  • Storage meets IOPS/latency requirements (Data nodes: 93K read / 31K write IOPS)
  • Disk I/O latency confirmed ≤ 20ms
  • Three separate ESXi hosts available for ND nodes
  • DRS disabled for ND VMs (or plan to disable per-VM)
  • vMotion disabled for ND VMs
  • Two separate networks available: Management and Data
  • Management and Data networks are in different subnets
  • IP addresses allocated: 3 per node (management IP, data IP) + 3-5 persistent IPs
  • DNS server accessible and reachable
  • NTP server accessible and reachable
  • OVA image downloaded from Cisco Software Download

With all of this confirmed, you’re ready to deploy. The next post covers the vCenter deployment procedure step by step.

// Found this useful? Share it or start a conversation.