Build an ONTAP 9.11.1 Simulator Cluster in VMware Workstation

This archived walkthrough imports the ONTAP 9.11.1 simulator into VMware Workstation, creates the first cluster node and joins a second simulator. It is a lab example. Reused English console captures remain source evidence; translated GUI figures and sanitized terminal reconstructions are identified below. No VM, cluster, password or license operation was performed while preparing this English article.

1. Prepare the simulator files and lab network

Obtain the simulator OVA, matching license material and installation guide through the authorized NetApp support download. The source file names are vsim-netapp-DOT9.11.1-cm_nodar.ova and CMode_licenses_9.11.1.txt:

English illustration of the ONTAP 9.11.1 OVA and license-file names — Only filenames are shown; the license file contents are not reproduced.

The source stored these in its company NAS/NetApp learning-materials folder, also pictured as an internal SharePoint library. This private location is not a public download service:

English illustration of the internal learning library with the two simulator files outlined — Private URL and people names are obscured. File sizes 689 MB and 3.29 KB are source-listing values, not download verification or integrity checks.

NetApp’s official download/support article links to ONTAP Simulate. The public portal did not expose the 9.11.1 installation-guide PDF during this review. Confirm that version’s actual prerequisites and supported VMware release in the guide supplied with the download; older guides are not compatibility proof for 9.11.1.

Prepare VMware Workstation and plan a unique cluster-management IP address plus a separate node-management IP for each node. Connect the simulator cluster ports to the same intended private virtual network and make the management network reachable from the host. Do not reuse the example addresses on a network where they conflict. Two lab members do not by themselves demonstrate hardware HA or storage-failover support.

2. Import and start the first VM

Open the OVA with VMware Workstation. Give the VM a name and local storage path, then Import. The source example uses cluster-node01 and F:\VM\cluster-node01:

English VMware import dialog with cluster-node01 and its F drive storage path

Wait until import finishes before powering on the VM. The supplied progress image shows import still underway:

English illustration of an incomplete VMware import progress bar — The short green segment is preserved; no percentage or completed-import result is asserted.

3. Log in and set the administrator password

Open the simulator console and follow the downloaded version’s initial-login instructions. Use the authorized initial credentials where required, then set an appropriate lab administrator password. The English documentation omits the source’s password values and all key material.

Sanitized reconstruction of the source boot excerpt, retaining the missing-file and missing-management-IP messages — The source includes ERROR: Missing pmroot_late.tgz file and UNABLE TO FETCH NODE MANAGEMENT IP. These messages have not been rewritten as a healthy boot, and the source does not supply a verified resolution for them. Diagnose an actual boot failure with the applicable guide before continuing.

The ONTAP 9.11.1 password command supports changing the specified account’s password interactively. The illustration below uses checked command syntax rather than claiming to reproduce the cropped source command exactly:

security login password -username admin

Illustrative password-change prompts with all values omitted — This is a sanitized explanation, not a new console result. No current or new password is supplied.

4. Create the first cluster member

Start the CLI setup wizard:

cluster setup

Original English cluster setup welcome screen and confirmation

Supply the actual management interface settings. The source chooses e0c, node-management address 192.168.123.201, mask 255.255.255.0 and gateway 192.168.123.2. It then continues with the CLI rather than the offered browser path and selects create:

Original English node-management settings and create-cluster choice

The source calls this stage a single-node cluster, but the actual answer to “used as a single node cluster?” is no. Its added “single node: yes” annotation is inconsistent with that input. For the subsequent two-member example, preserve the actual no choice; a deliberately permanent single-node configuration is a different choice. The later yes accepts the existing cluster-interface configuration:

English illustration distinguishing single-node choice no from reuse-interfaces choice yes — Corrected explanatory annotations; underlying no/yes inputs and addresses remain as captured.

The existing cluster ports are e0a/e0b, MTU 9000, with automatically assigned link-local addresses 169.254.242.182 and 169.254.242.192 and mask 255.255.0.0. These are private cluster-interface addresses, not the external management IPs. The example cluster name is test_cluster:

Original English console naming and creating test_cluster

Sanitized cluster-creation and license-prompt illustration — Credential-related output is omitted. This excerpt ends during setup and does not supply license material or a new completion result.

Continue the wizard with the actual cluster-management, DNS and other requested information. The next source crop selects e0c instead of the offered e0d default and sets cluster-management address 192.168.123.200 with mask 255.255.255.0; the displayed default gateway is 192.168.123.2:

Original English cluster-management IP settings for 192.168.123.200

The official 9.11.1 setup reference documents the wizard’s information requirements and distinguishes node and cluster management. The pictured addresses and ports are this source’s lab choices, not universal defaults.

5. Add the matching simulator licenses

Use license material supplied for the intended simulator release and node identity. The source reports one CIFS license installed, but its actual key and license-associated serial details are omitted. The following illustration uses a placeholder only:

Sanitized license-installation illustration containing only a nonusable placeholder — The source reports one installed license. No new license command was executed or validated here; the placeholder is not a usable key.

The 9.11.1 command reference documents system license add -license-code. Follow the licensing mechanism supplied for the particular download; do not treat this old per-key example as evidence that every current entitlement uses the same format.

6. Import a second VM and give it a distinct simulator identity

Import another VM from the OVA, as in step 2. Before joining it, use the simulator loader to inspect and set its identity. The source mentions Ctrl+C, but its captured VLOADER screen explicitly offers any non-Enter key during the countdown for the command prompt. Use the prompt actually displayed; the later Ctrl+C ONTAP boot menu is a different stage:

Original English VLOADER countdown and command prompt

The case uses these public simulator example values for the second node:

VLOADER> printenv SYS_SERIAL_NUM
VLOADER> printenv bootarg.nvram.sysid
VLOADER> setenv SYS_SERIAL_NUM 4034389-06-2
VLOADER> setenv bootarg.nvram.sysid 4034389062
VLOADER> printenv SYS_SERIAL_NUM
VLOADER> printenv bootarg.nvram.sysid
VLOADER> boot

Ensure the two members have distinct system IDs before joining; the values above are simulator identifiers, not license keys or instructions to alter real storage hardware. NetApp’s older Simulate ONTAP 9.3 guide, pages 36–37, documents the same example identity change. It corroborates this mechanism only; use the 9.11.1 guide for that release’s complete initialization sequence and VMware requirements. Do not apply any clean-configuration/disk-initialization step from an older guide to an existing data-bearing system.

7. Join the second node through the cluster network

On the first cluster member, use the web interface at the cluster-management address to inspect network interfaces. The source table shows first-node cluster LIFs at 169.254.242.182/e0a and 169.254.242.192/e0b, node management 192.168.123.201/e0c and cluster management 192.168.123.200/e0c:

English first-node interface table with the two cluster and two management interfaces

The source says to record clus1. Its table highlights clus2 (169.254.242.192), while the actual join command uses clus1 (169.254.242.182). These are different addresses; use a reachable cluster-network LIF of the existing member, not an arbitrarily highlighted management address. The archived second-node command and result are:

cluster join -clusteripaddr 169.254.242.182

Original English join command reporting the node joined test_cluster

This preserves the historical workflow. The 9.11.1 command reference already marks cluster join as deprecated and directs administrators to discover/add nodes from an existing cluster member. Check the supported procedure for the lab version rather than extending this old command to newer systems.

8. Verify membership and finish node management

From node 1, check membership and interfaces:

cluster show
network interface show

Original English cluster show output listing two healthy and eligible members

Original English six-interface output showing both nodes cluster LIFs and first-node management LIFs

The membership capture lists test_cluster-01 and test_cluster-02 with Health and Eligibility true. The interface output has four cluster LIFs: node 1 uses 169.254.242.182/16 and 169.254.242.192/16; node 2 uses 169.254.241.196/16 and 169.254.241.206/16. All are shown up/up. Cluster management 192.168.123.200/24 and node 1 management 192.168.123.201/24 are also shown.

Thus the source’s statement that node 2 has no LIF is too broad: node 2 has two cluster LIFs, but no separate node-management LIF appears in this output. Add the required node-management interface through the applicable GUI or CLI using the planned unique address, correct home node/port and management service policy. The 9.11.1 LIF-create reference documents those parameters. The source does not specify a node-2 management IP, so none is invented here.

Verify that interface and management reachability afterward, and install any remaining matching simulator licenses as required. The provided captures establish membership and the six listed interfaces at that recorded moment; they do not include a final second-node management-LIF creation result, all-license validation, data-service test or HA failover test.