Remote PC Guide Series - Volume 3

Configuring the NETLAB+ Virtual Machine Infrastructure

Document Version: 2016-11-21

This guide provides guidance on connecting the vSphere setup to the NETLAB+
environment.

This guide is part of a multi-volume series, designed to provide you with the guidance
needed to implement remote PCs on your NETLAB+ system. Learn more about the
Remote PC Guide Series. See the Documentation Library for a list of all NETLAB+ guides.

Before following the configuration tasks detailed in this guide, please complete all
installation and configuration instructions provided in Remote PC Guide Series - Volume
2, Installation.

Copyright © 2016 Network Development Group, Inc.

www.netdevgroup.com

NETLAB Academy Edition, NETLAB Professional Edition, and NETLAB+ are registered trademarks of Network Development Group,
Inc.

VMware is a registered trademark of VMware, Inc. Cisco, IOS, Cisco IOS, Networking Academy, CCNA, and CCNP are registered
trademarks of Cisco Systems, Inc.
Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

1 Background ................................................................................................................. 3
2 Registering a Virtual Datacenter in NETLAB+ ............................................................. 3
3 Adding ESXi hosts in NETLAB+ .................................................................................... 7
4 Proactive Resource Awareness ................................................................................. 10
5 NETLAB+ Virtual Machine Inventory......................................................................... 12
5.1 Virtual Machine Roles ........................................................................................ 12
5.2 How Virtual Machines Become Part of the NETLAB+ Inventory........................ 13
5.3 Importing VMs into the Virtual Machine Inventory........................................... 14
5.4 Virtual Machine Cloning ..................................................................................... 16
5.4.1 Golden Masters and Golden Snapshots ..................................................... 17
5.4.2 Using NETLAB+ to Clone a Single Virtual Machine ..................................... 17
5.5 Assigning Virtual Machines to Pods ................................................................... 21
5.5.1 Configuring Control Switch 802.1q Trunk Ports ......................................... 27
5.5.2 Connecting Virtual Machines to Real Equipment Pods .............................. 29
5.5.2.1 Creating a Real Equipment Pod ........................................................... 30
5.5.2.2 Determining the Base VLAN and VLAN Pool ....................................... 30
5.5.2.3 Creating Port Groups for Pod VLANs on the Inside Network .............. 31
5.6 NDG Virtual Machine Topologies ....................................................................... 31
6 Cloning Virtual Machine Pods ................................................................................... 32
6.1 Golden Masters and Golden Snapshots ............................................................. 34
6.2 Creating a Master Pod........................................................................................ 34
6.3 Cloning a Virtual Machine Pod Using Linked Clones .......................................... 35
6.4 Tasks to Perform After Pod Cloning ................................................................... 38
6.5 Saving Time on Subsequent Pod Cloning .......................................................... 38
6.6 Creating a Full Clone of a Virtual Machine Equipment Pod ............................... 39
6.7 Creating Pods that Run on a Multiple VMware ESXi Hosts................................ 40
7 Virtual Machine Operations ...................................................................................... 42
7.1 Delete All Virtual Machines in a Pod .................................................................. 43
7.2 Deleting Individual Virtual Machines ................................................................. 45
7.3 Changing the Name of a Virtual Machine .......................................................... 46
7.4 Changing the Role of a Virtual Machine............................................................. 47
8 Using NDG Automated Pods ..................................................................................... 49
8.1 NDG Real Equipment Topologies ....................................................................... 49
8.2 Setting the Local System ID When Using Multiple NETLAB+ Systems ............... 50

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 2

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

1 Background

This guide is designed to help you attach the Virtual Machine Infrastructure you created
in: Remote PC Guide Series - Volume 2, Installation.

NETLAB+ maintains a database called the Virtual Machine Inventory. The inventory is a
mapping between NETLAB+ remote PCs and virtual machines in one or more vSphere
datacenters. The inventory also tracks information about virtual machines that is not
stored in vCenter, such as the role each VM plays in NETLAB+ and parent/child
relationships between virtual machines.

2 Registering a Virtual Datacenter in NETLAB+

In this section, you will add vCenter datacenter(s) created during the Virtual Machine
Infrastructure setup to NETLAB+.

1. Login to the NETLAB administrator account.

2. Scroll down and click on Virtual Machine Infrastructure.

3. Click on Virtual Datacenters and Management Agents.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 3

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

4. Click on Add Datacenter.

5. Enter the required information for the datacenter you have set up using the
vSphere Client. Field descriptions are provided below.

The values for this form may vary based on your local settings.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 4

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

a. Datacenter Name: The exact name of the datacenter as registered in

vCenter (see the red box below). This will be NETLAB if you used the
recommended name when adding a datacenter in vCenter.

b. Agent Hostname: This value is set to an IP address assigned to your

vCenter server. The following table depicts which IP address you should
use based on the model you selected.

Network Model Management Path IP Address

Single-Homed OUTSIDE Campus LAN IP
Dual-Homed OUTSIDE Campus LAN IP

c. Agent Username: Enter the username for the account you created when
configuring the vCenter Server Appliance. If you followed the guide, this
username should be administrator@your_domain_name. This
username will be used when NETLAB+ connects to vCenter.
d. Agent Password: Enter the password for the account you created when
configuring the vCenter Server Appliance. If you followed the guide, this
is a custom password. This password will be used when NETLAB+
connects to vCenter.
6. Click Add Datacenter to complete the registration.
7. Click on OK to continue.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 5

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

8. Click Test to verify that NETLAB+ can connect to vCenter server using the settings
you provided. If the test fails, recheck connectivity and your datacenter settings.

9. Click on OK to continue.
10. Click Exit to return to the datacenter list.
11. Click Exit to leave the datacenter list.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 6

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

3 Adding ESXi hosts in NETLAB+

In this section, we will add the virtual machine host servers in your datacenters to
NETLAB+.

1. Login to the NETLAB administrator account.

2. Scroll down and click on Virtual Machine Infrastructure.

3. Select Virtual Machine Host Servers.

4. Click on Add Host.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 7

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

5. If you have more than one datacenter defined, you will be prompted to select a
datacenter. NETLAB+ scans the datacenter to discover hosts. Hosts that have
not been registered in NETLAB+ are displayed. Select the host you wish to add
by clicking on the host name.

6. Enter the settings for this host based on the networking model you have chosen.
The table below shows typical settings.

Inside Communication
Networking Model Outside Address Inside Address
vSwitch Path
Single-Homed Campus LAN IP address Not set Not applicable Outside
Dual-Homed Campus LAN IP address 169.254.0.X vSwitch1 Outside

Host Name. The IP address or fully qualified domain name of the ESXi host. This should
be the same value entered in vCenter for the host name.

Outside IP Address. The IP address of the ESXi host outside interface.

Inside IP Address. The IP address of the ESXi host inside interface. Use the "not set"
option for single-homed networking. This setting is only used in the dual-homed
environment.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 8

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

Communication Path. This setting determines the network path that is used for remote
display connections (proxied by the NETLAB+ server). This will always be set to outside
network. Inside network was for compatibility with previous networking models.

Inside vSwitch Name. This is the name of the virtual switch that connects to your
control switch. This is typically "vSwitch1" for dual-homed networking. Leave this
setting blank for single-homed networking (which does not connect to a control switch).

The Inside vSwitch Name is case sensitive and must be entered exactly as shown in
vCenter. This setting must be correct to use automatic networking on real equipment
pods (i.e. MAP, CRP, BRPv2).

Proactive Resource Awareness. See the next section for details.

7. Click OK to confirm the host has been added.

8. Click Exit to return to host list.
9. Repeat this section for each ESXi host in your Virtual Machine Infrastructure.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 9

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

4 Proactive Resource Awareness

Proactive Resource Awareness (PRA) allows you to time-share virtualization servers

using the NETLAB+ scheduler. PRA is designed with 3 goals in mind.

1. Ensure a quality lab experience for all trainees by reserving CPU and memory
resources on VM servers at the scheduled lab times. This proactively prevents
the VM servers from becoming overloaded and unresponsive.

2. Increase the number of trainees that you can run through your training programs
by spreading out the trainee lab sessions over time.

3. Reduce costs of your training programs by using fewer virtualization servers.

For each VM server in your inventory, you may set 3 limits.

• Total number of active virtual machines

• Active number of virtual CPUs
• Active maximum memory usage

With these limits defined, the scheduler will proactively manage the server's CPU and
memory resources. If scheduling a particular pod would exceed one of the set limits in a
30-minute time slot, the pod cannot be scheduled at that time and the limitation will be
clearly indicated on the scheduler.

PRA is enabled in Virtual Machine Host Servers on a per host basis. You can enable PRA
when adding a host or editing the host settings of an existing host.

Administrator Account > Virtual Machine Inventory > Virtual Machine Host Servers

The values you set for PRA will depend on your host server specifications and the types
of workloads that you run on your servers.

Proactive Resource Awareness is a scheduling algorithm based on workload forecasting;

it does not monitor real time workload. PRA assumes that all virtual machines running
on a host server are under the control of NETLAB+; it does not account for VMs that are
powered on independently of NETLAB+.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 10

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

• Proactive Resource Awareness. Check this box to enable PRA on this host.
Uncheck the box to completely disable PRA on this host.

• Maximum Running VMs. To set the maximum number of virtual machines that
can be scheduled at one time on this host, check enable this limiter and set the
number of virtual machines.

• Maximum Virtual CPUs. VMware ESXi supports VMs with more than one virtual
CPU (vCPU) and Symmetric Multiprocessing. Virtual machines with more than
one vCPU typically use more processing power on the host than VMs with only
one vCPU. The number of vCPUs assigned to a VM can be seen when viewing
the Virtual Machine Inventory table in NETLAB+. By setting Maximum Virtual
CPUs, you can achieve more granular control over CPU resources. Check enable
this limiter and set the number of virtual CPUs that can be running at one time.

• Maximum Memory Usage. This setting limits the amount of memory (in
Megabytes) that can be scheduled for VMs at one time. It is based on the
memory assigned to the virtual machines when the VM was created. It does not
include overhead memory required for the VMs or the host. For best
performance, this value should not be set higher than the physical memory on
the host. A general rule of thumb is to take the total amount of RAM and
subtract 8GB or 8192MB.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 11

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

5 NETLAB+ Virtual Machine Inventory

NETLAB+ version 2011 introduced the Virtual Machine Inventory (VMI). The inventory is
a mapping between NETLAB+ remote PCs and virtual machines in one or more vSphere
datacenters. The inventory also tracks information about virtual machines that is not
stored in vCenter, such as the role each VM plays in NETLAB+ and parent/child
relationships between virtual machines.

5.1 Virtual Machine Roles

Each virtual machine is assigned a role in the NETLAB+ inventory. This is a NETLAB+
specific value that is not stored in vCenter. The role indicates the intended function of
the virtual machine in NETLAB+ and influences the operations that can be performed on
the virtual machine, as well as default settings during those operations. The following
roles are currently defined:

Template. A template is a virtual machine that is used to deploy other virtual

machines. Templates cannot be assigned to pods, powered on or edited,
providing a more secure way of preserving a virtual machine configuration that
you intend to deploy many times. A template VM in NETLAB+ is synonymous
with a template VM in VMware vCenter. Virtual machines marked as templates
in vCenter are always marked as templates in NETLAB+, and vice-versa.

Master. By designating a virtual machine as a master, you indicate your

intention to use the virtual machine for the purpose of cloning other virtual
machines and/or cloning the virtual machine as part of a cloned pod. When you
clone VMs from a master, and subsequently choose to clone a VM from that
clone, the default selection will be to create the clone from the original that was
indicated to be the Master. A master VM differs from a template VM in that can
be assigned to run on a host, used in a pod (typically a master pod), and

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 12

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

powered on for the purpose of adding and configuring new software. Once the
virtual machine has all the required software components and is thoroughly
tested, a golden master snapshot is taken and becomes the basis for full or
linked clones (discussed later).

Normal. A normal VM is a virtual machine that will be assigned to a production

pod. A normal VM may be configured to revert to a snapshot at the beginning
and end of a lab reservation, or when the user explicitly invokes the scrub action
on the VM or the entire pod. A normal VM is an ideal choice for pods that
should always start in the same state, such as VMs in Cisco NetAcad pods.

Persistent. A persistent VM is assigned to a production pod, with the additional

characteristic that its state will be retained from one reservation to the next. A
persistent VM never reverts to a snapshot. This type of VM is appropriate when
the user assigned to the pod is working on a curriculum that carries the result of
each lab assignment progressively. An example scenario would be a course
where the student performs “Lab One” and then on a subsequent reservation
performs “Lab Two”, with the pod in the state it was in at the end of “Lab One”.

5.2 How Virtual Machines Become Part of the NETLAB+ Inventory

Virtual machines must first reside in the NETLAB+ Virtual Machine Inventory before they
can be assigned to pods and function as NETLAB+ remote PCs. There are three ways
virtual machines can become part of the NETLAB+ inventory:

• Import. NETLAB+ communicates with vCenter and scans the selected datacenter
to identify existing VMs that are available to be added to the NETLAB+ virtual
machine inventory. The import function is used to import virtual machines that
were created outside of NETLAB+ (i.e. from the vSphere Client or VMware
Converter).

• Clone VM. NETLAB+ communicates with vCenter and makes a copy of a virtual
machine that already exists in the NETLAB+ inventory. When a virtual machine is
cloned from the NETLAB+ inventory, the new virtual machine is added to both
the NETLAB+ inventory and vCenter in one operation. NETLAB+ also supports
linked clones (virtual machines that share disk content with another parent
virtual machine).

• Clone Pod. If a pod contains only virtual machines, NETLAB+ can clone the entire
pod in one operation. Each virtual machine in the source pod is cloned and
added to both the NETLAB+ inventory and vCenter in one operation.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 13

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

5.3 Importing VMs into the Virtual Machine Inventory

The following procedure is used to import an existing virtual machine or template from
vCenter into the NETLAB+ Virtual Machine Inventory.

1. From the Advanced Virtual Machine Infrastructure Administrator page, select

Virtual Machine Inventory. All virtual machines in the inventory are listed. If
this is your first time importing VMs to the inventory, there is no list displayed.

2. Click the Import Virtual Machines button at the bottom of the page to add VMs
to the inventory. If you have added more than one datacenter to your NETLAB+
system, you will be prompted to select a datacenter.

3. NETLAB+ will scan the datacenter to discover virtual machines that are not
currently in the inventory. You may then click the checkbox next to the virtual
machine(s) you wish to import and then click Import Selected Virtual Machines.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 14

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

4. Select the appropriate configuration settings for each virtual machine.

• Operating System: This should match the operating system installed on the
virtual machine. The default value is usually correct. However, if the virtual
machine is running a nested/virtualized instance of VMware ESXi, you should
change this value from "Other" to "VMware ESXi".

• Role: Select the role that this virtual machine will play in your inventory (see
Section 5.1 for definition of roles). If the virtual machine is marked as a
Template in vCenter, it will also be set to Template in NETLAB+ (no selection is
provided in this case).

• Runtime Host/Group: Select the physical VMware ESXi host that will run the
virtual machine. The host currently assigned in vCenter is the default choice for
virtual machines that are not marked as templates (master, normal, or persistent
VMs). Template VMs cannot be powered on and therefore cannot be assigned
to a host.

The runtime host should not be changed unless the virtual machine's disk files reside on
a SAN and all physical ESXi hosts have access to the virtual machine disk files.

5. After selecting configuration settings and selecting Import Virtual Machines, the
VMs will be added to the inventory.
6. Select OK to return to the virtual machine inventory.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 15

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

7. The imported VM is now displayed in the virtual machine inventory.

5.4 Virtual Machine Cloning

Cloning virtual machines can save you a substantial amount of setup time if you are
deploying many similar virtual machines. A clone is a copy of a virtual machine. Cloning
a virtual machine creates a copy of a virtual machine, including its settings, any
configured virtual devices, installed software, and other contents of the virtual
machine's disks. You can create, configure and install software on a single virtual
machine, and then clone it multiple times.

After a virtual machine is cloned, the clone can be modified as needed. For example,
you may wish to change the IP address or client name on several cloned virtual
machines. If there is a particular virtual machine configuration that you will want to
clone many times, a good strategy is to create a master VM or template VM. Both roles
designate that the virtual machine is to be used to create other virtual machines. A
master VM can be part of a pod and can be powered on. A template cannot be
powered on or edited, providing a more secure way of preserving a virtual machine
configuration that you intend to deploy many times. A template VM in NETLAB+ is
synonymous with a template VM in vSphere.

A full clone is an independent copy of a virtual machine that shares nothing with the
parent virtual machine after the cloning operation. Ongoing operation of a full clone is
entirely separate from the parent virtual machine.

A linked clone is a virtual machine that shares virtual disks with the parent virtual
machine in an ongoing manner. This conserves disk space and allows multiple virtual
machines to use the same software installation. Linked clones can be created very
quickly because most of the disk is shared with the parent VM.

It is possible to create full clones using the VMware vSphere Client. Keep in mind,
however, that cloning operations in NETLAB+ update both VMware vCenter and
NETLAB+ inventory in one operation.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 16

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

5.4.1 Golden Masters and Golden Snapshots

Master virtual machines and templates should be thoroughly tested before making
production clones (full or linked). A master virtual machine (or template) that has been
tested and deemed to be production quality is called a golden master. Linked clones
also require a pristine snapshot that becomes the base disk for linked clones. This
snapshot is called a golden snapshot.

Keep in mind the following important rules about golden snapshots.

1. Updates to the golden snapshot only affect NEW clones (full or linked).

2. Updates to the golden snapshot do not affect EXISTING clones (full or linked).
Since snapshots operate on disk sectors and not individual files, this would lead
to disk corruption and is prevented by vSphere.

It is inevitable that at some point your master VMs will need to be updated, either in
response to a defect or to install new files. When this need arises, you must decide
whether to update existing clones, or create them over again. Since linked clones can
be made very quickly (including pod cloning), it may be easier to simply re-clone from
the updated master VMs. Should you decide to update existing clones, be sure to
create a new snapshot on each clone if the clone is a normal VM that reverts to
snapshot.

5.4.2 Using NETLAB+ to Clone a Single Virtual Machine

NETLAB+ provides a convenient way to clone virtual machines. In order to clone virtual
machines within NETLAB+, you must first create a source virtual machine to be used as
the source for the clone. Creating virtual machines is discussed in detail in
Remote PC Guide Series - Volume 4, Creating and Configuring Virtual Machines for
NETLAB+. The source virtual machine must also be registered in the NETLAB+ inventory.

1. To clone a virtual machine, select the source virtual machine to be cloned in the
NETLAB+ Virtual Machine Inventory. In this example we have a selected a virtual
machine that has been designated a master. Notice also that since this virtual
machine has been assigned to a pod, the pod name and link to the pod
management page are available.
2. Begin the cloning process by selecting the Clone button.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 17

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 18

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

3. The Clone Virtual Machine screen will be displayed. Select the appropriate
settings for the fields as described below.

• Parent Name: The name of the existing parent virtual machine. In this example
we are making a clone of a virtual machine designated as a master. This master
is the parent of the virtual machine.

• Parent Role: The role the parent virtual machine plays in the inventory.

• Parent Snapshot: A snapshot name on the parent virtual machine from which to
base the clone. If this parameter is set, the clone is based on the snapshot point.
This means that the newly created virtual machine will have the same
configuration as the virtual machine at the time the snapshot was taken. If this
property is not set, the clone is based on the virtual machine's current
configuration. Linked cloning requires this parameter to be set to a snapshot.

• Clone Name: The name of the new virtual machine.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 19

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

• Clone Type: There are two types of clones:

o Linked Clone: A copy of a virtual machine that shares virtual disks with
the parent virtual machine in an ongoing manner. This conserves disk
space and allows multiple virtual machines to use the same software
installation. Linked clones can be created very quickly because most of
the disk is shared with the parent VM.

o Full Clone: An independent copy of a virtual machine that shares nothing

with the parent virtual machine after the cloning operation. Ongoing
operation of a full clone is entirely separate from the parent virtual
machine.

• Clone Role: Assign the clone to the role it will play in the inventory.

o Template: A pristine virtual machine image used as the basis for cloning
many virtual machines. Template VMs cannot be powered on, modified,
or assigned to pods.

o Master: A virtual machine used as the basis for cloning other virtual
machines. Master VMs can be assigned to pods, modified and powered
on.

o Normal: A virtual machine that can be assigned to a pod. A normal VM

will typically revert to a specified snapshot at the start of a lab
reservation.

o Persistent: A virtual machine that can be assigned to a pod and retains

its state between labs. A persistent VM is typically used in conjunction
with Pod Assigner to create long-term personal pods.

• Runtime Host: The host server where the virtual machine will run.

• Datastore: The VMware datastore that will contain the new VM's virtual disk
files.

• Storage Allocation: Indicate the type of storage allocation to be used for the
virtual machine.

o On Demand allocates storage for the new virtual machine as needed; this
favors storage reduction at the expense of decreased write performance.

o Preallocated allocates all storage for the new virtual machine in advance;
this favors better write performance at the expense of increased storage.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 20

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

4. Indicate the appropriate selections for each field and then click the Clone button
to initiate the cloning process. The results of the process will be displayed.

5.5 Assigning Virtual Machines to Pods

The virtual machines residing in the Virtual Machine Inventory must be assigned to an
equipment pod in order to be available to users for scheduled access. Remote PCs are
only available in pods where the network topology indicates the existence of lab PCs.

In this section, we will discuss the methods that may be used to assign virtual machines
to equipment pods.

1. Select the Equipment Pods administrator option. As an example, we will use a

newly created equipment pod that is designed to include one PC. For details on
creating equipment pods refer to the “Adding New Pods” section of the NETLAB+
Administrator Guide Notice that the type of the PC/VM is indicated as
“ABSENT”. This is the default setting for PCs in new pods.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 21

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

2. To display the PC settings, select the button to the left of the PC name.

3. Select the option to Modify PC Settings.

4. Set the PC Type to Use Virtual Machine Inventory. This will allow you to use a
virtual machine defined in the Virtual Machine Inventory (VMI). The other
selections are for backward compatibility with other technologies that do not
integrate with VMI and vCenter.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 22

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

5. If your system includes more than one datacenter, you will be prompted to
select the datacenter where the virtual machine you will be selecting resides.

6. Select the virtual machine that you would like to assign to the remote PC.
All virtual machines in your Virtual Machine Inventory that have not been
assigned to a pod will be available for selection.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 23

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

7. After selecting a virtual machine from the inventory list, you will set the PC
configuration. Select the settings appropriate for the manner in which you will
use the virtual machine. The PC settings are described below.

• Pod ID: The NETLAB+ identifier of the pod containing this PC.

• Pod Name: The user-defined name of the pod containing this PC.

• PC Name: The name of the PC as defined in the pod design.

• PC Type: The setting should remain at Use Virtual Machine Inventory. This
allows you to select a virtual machine defined in the NETLAB+ Virtual Machine
Inventory. The VMI offers the most advanced VM configuration and automation
capabilities available in NETLAB+.

• Base Datacenter: The virtual datacenter that contains the virtual machine to be
used for this PC (unless overridden by a lab).

• Base Virtual Machine: The virtual machine that will be used for this PC.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 24

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

• Base Role: The pre-assigned role that the base virtual machine plays in the
inventory.

• Base Snapshot: The snapshot that will be used to revert the base virtual
machine to a clean state during pod initialization, user initiated scrub action, and
at the end of a lab reservation. This setting does not apply to persistent VMs
because that always retain state.

• Shutdown Preference: Select the preferred shutdown sequence if the virtual

machine is still powered on at the end of a lab reservation. If a base snapshot is
configured, it is reverted first. If the virtual machine is still powered on after
reverting to the specified snapshot, the preferred shutdown sequence is
executed. Otherwise, the final power state will be the same as the snapshot
state.

o Graceful Shutdown from Operating System: Perform an orderly

shutdown from the operating system if possible (i.e. VMware Tools is
supported and installed on the VM). This is best setting in most
situations. If an orderly shutdown is not possible, the virtual machine is
powered off.

o Power Off: Powers off the virtual machine. Does not perform an orderly
shutdown.

This option is not recommended for persistent virtual machines as this

may lead to disk corruption.

o Suspend Virtual Machine: Suspend the virtual machine in its current

state. When powered on, it will resume in the same state without
booting.

This option will cause virtual machines memory and page files to be
retained on disk. Significant disk space per VM may be required to
support this option. Network connection state is not preserved.

o Keep Running: The virtual machine is left in the powered on state.

This is rarely desirable since the VM will continue to consume host CPU
and memory resources.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 25

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

• Guest Operating System: The operating system running on this virtual machine.

• Options: Enable or disable automated features.

o Enable remote access to keyboard, video, and mouse: if enabled,

NETLAB+ will allow the virtual machine to be accessed using a built-in
remote PC viewers. Keep this option enabled unless you do not want
users to access the VM; for example, a special server in the pod that
should not be configured by the user.

o Enable remote display auto-configuration: if enabled, NETLAB+ will

automatically configure remote display parameters on the VM after a
power on or revert to snapshot operation. This option allows VMs to be
cloned without manual customization of the remote display settings.
Therefore, we recommend you enable this setting and be happy about it.

o Enable network auto-configuration: if enabled, NETLAB+ will

automatically bind the virtual machine's network adapters to the correct
port group. This option allows VMs to be cloned without manual
customization of networking bindings. This option is ignored if the pod
type does not support automatic networking. If this setting is disabled
and/or the pod type does not support automatic networking, then the
virtual machine network adapters must be manually bound to the correct
port group(s) using the vSphere client.

o Enable advanced setting auto-configuration: if enabled, NETLAB+ will

automatically program advanced virtual machine settings that may be
required for a particular pod type. For example, nested VM support for
the VMware IT Academy program. It is usually safe to enable this option.
It will be ignored if the pod type does not require advanced settings.

o Enable minimum requirements verification: if enabled, NETLAB+ will

verify that the current settings of the virtual machine meet or exceed any
minimum requirements established for the remote PC to which it is
assigned. It is usually safe to enable this option. The setting will be
ignored if the pod type does not specify a set of minimum requirements
for the remote PC.

• Admin Status: Set administrative status to ONLINE to enable this PC. You can
temporarily disable this PC by setting the administrative status to OFFLINE.

After updating all PC configuration settings as needed, select Modify PC Settings.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 26

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

9. After the settings have updated, you may continue to the Pod Page or the PC
page.

5.5.1 Configuring Control Switch 802.1q Trunk Ports

To allow virtual machines to communicate with real equipment pods, configure 802.1q
trunk mode on all control switch ports connecting to your ESXi inside vmnics. In
addition, all uplinks between control switches must also be 802.1q trunks.

You must console into the control switches to perform this action. The control switch
console password is router. The enable secret password is cisco. These passwords
are used by NETLAB+ automation and technical support - please do not change them.

interface x/x
description inside connection for ESXi Server
switchport mode trunk
switchport nonegotiate
no switchport access vlan
no shutdown

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 27

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

After you have configured the control ports for ESXi inside host connections and inter-
switch uplinks, verify that the ports are up and operating in trunk mode.

1. Verify each ESXi host control port and inter-switch uplink is connected and line
protocol is up. Substitute the designated interfaces names for x/x.

netlab-cs1# show interface x/x

x/x is up, line protocol is up (connected)

2. Verify each ESXi host control port and inter-switch uplink is operating in 802.1q
trunk mode.

netlab-cs1# show interface trunk

Port Mode Encapsulation Status Native vlan

x/x on 802.1q trunking 1
x/x on 802.1q trunking 1
x/x on 802.1q trunking 1

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 28

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

5.5.2 Connecting Virtual Machines to Real Equipment Pods

This section discusses the configuration of networks to communicate between virtual

machines and real lab devices in the topology. You can skip this section if your virtual
machines do not need to communicate with real lab equipment.

Virtual machines [7] running on an ESXi host talk to real equipment pods [12] using port
groups [6], the inside virtual switch [3] and control switches [9]. Inside networking is
always used for this purpose. In the last two sections, you established an inside network
connection and configured 802.1q VLAN trunking on the link connecting to your control
switch [8].

A real equipment pod may have one or more networks. 802.1q virtual LANs (VLANs) are
the glue that binds virtual machines [7] and real equipment [12] with the proper pod
networks. A unique set of VLAN identifiers for each pod is automatically allocated by
NETLAB+ and programmed into the control switches [9] by NETLAB+ when the pod is
created. Port groups [6] are assigned to a specific VLAN ID, thereby allowing virtual
machine network adapters [5] to be placed in a specific VLAN.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 29

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

As of version 2011.R2, NETLAB+ will automatically setup and teardown VLAN based port
groups on the inside vSwitch on NDG standard pods.

Automatic network setup on NDG standard pods occurs when a pod is reserved.
Automatic network teardown on NDG standard pods occurs when a reservation
completes. These features are enabled by default but can be disabled on a per pod
basis.

Refer to "Appendix A" of the Remote PC Guide for VMware Implementation Using ESXi
versions 4.01 and 4.1 U2 with vCenter for setup of pods that require manual networking,
such as custom pods.

5.5.2.1 Creating a Real Equipment Pod

Creating a real equipment pod in NETLAB+ should be done first. This will automatically
generate the required number of VLANs for the selected pod type, and add those VLANs
to the control switches. This should be done before ESXi host networking is configured.

1. Login to the NETLAB+ administrator account.

2. Select Equipment Pods.
3. Click the Add a Pod button at the bottom of the page.
4. Select the desired pod type. Only pod types that use both real lab equipment
and remote PCs are relevant to this section. Our examples use the Multi-
purpose Academy Pod, which contains 3 routers, 3 switches, and 3 remote PCs.
5. Complete the New Pod Wizard. Please refer to the NETLAB+ Administrator
Guide, NDG website pod specific web pages, and NDG pod guides for pod
specific installation instructions.

After the pod is created, you will be placed in the Pod Management page. You will
notice that all virtual machines are initially ABSENT. You will add virtual machines to the
pod later.

5.5.2.2 Determining the Base VLAN and VLAN Pool

This is now an automated task for NDG standard pods as of NETLAB+ version 2011.R2.
Refer to "Appendix A" of the Remote PC Guide for VMware Implementation Using ESXi
versions 4.01 and 4.1 U2 with vCenter for manual networking setup guidance for custom
pods or pods that do not support automatic networking.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 30

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

5.5.2.3 Creating Port Groups for Pod VLANs on the Inside Network

This is now an automated task for NDG standard pods as of NETLAB+ version 2011.R2.
Refer to "Appendix A" of the Remote PC Guide for VMware Implementation Using ESXi
versions 4.01 and 4.1 U2 with vCenter for manual networking setup guidance for custom
pods or pods that do not support automatic networking.

5.6 NDG Virtual Machine Topologies

NDG standard topologies that contain only virtual machines can be replicated and
deployed very quickly using a combination of pod cloning, automatic networking and
automatic remote display setup features.

The list of NDG automated virtual machine topologies includes:

• 25 automated client/server pods for General IT usage. For details see

http://www.netdevgroup.com/content/generalit

• Automated topologies are available for a variety of NETLAB+ supported content,

developed in collaboration with leading industry training programs, including:

o VMware IT Academy Program®

o EMC Academic Alliance®
o Linux Professional Institute
o Red Hat® Academy

Once production pods are created using the pod cloning utility, they are ready to go.
When an automated pod is scheduled and lab reservation begins, the following
automation takes place:

• NETLAB+ will automatically create virtual switches and port groups required for
the pod.
• NETLAB+ will bind the virtual network adapters of each VM to the correct port
group.
• NETLAB+ will configure remote display parameters automatically.

When the lab reservation is over, NETLAB+ will tear down the virtual switches and port
groups created for the pod to free resources on the host.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 31

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

6 Cloning Virtual Machine Pods

The ability to clone entire virtual machine pods is a NETLAB+ feature that greatly
reduces the amount of time needed for setup of your system, when the situation calls
for several identical equipment pods consisting of virtual machines.

Pod cloning may be used to clone pods that consist of virtual machines only. At this
time, it is not possible to clone pods that include hardware lab devices (such as routers
and switches).

NETLAB+ pod cloning supports linked clones. A linked clone is a virtual machine that
shares virtual disks with the parent virtual machine in an ongoing manner. This
conserves disk space and allows multiple virtual machines to use the same software
installation. The pod cloning utility can create linked clones very quickly because most
of the virtual disk is shared with the parent VM.

There are two basic pod-cloning strategies, depending on whether your virtual machines
will be stored on an ESXi host local disk or on a Storage Area Network (SAN). Both
strategies leverage linked clones so that production virtual machine pods can be created
quickly with minimum disk space.

Local Disk Strategy. If your virtual machines are stored on an ESXi server local disk, you
will create one master pod (per pod type) on each ESXi host. Production VMs on each
server will link to their respective master pod VMs. Each host requires a master pod
because Host A cannot access the disks of Host B, and vice-versa.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 32

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

Storage Area Network Strategy. Only one master pod (per pod type) is required if your
virtual machines are placed on a SAN. Virtual machines in the production pods will link
to the virtual machines in the master pod, regardless of which ESXi host the virtual
machines have been assigned to run on. This is possible because each ESXi host has
access to the storage area network (where all virtual disks reside).

NDG performs all testing on servers with Internal Direct Attached Storage (i.e. RAID
arrays and RAID controllers directly attached to each ESXi host server). This is the
configuration that most academic institutions are likely to find affordable and adopt.
A Storage Area Network (SAN) is a dedicated network that provides access to
consolidated, block level data storage that can be used for disk storage in a VMware
vSphere environment.

Currently NDG does not provide benchmarks, guidance or troubleshooting for SAN
configurations. Our documentation may show an optional SAN in the environment,
however this is not a recommendation or requirement to deploy a SAN.

NDG benchmarks and capacity planning guidance do not account for the additional
latencies introduced by SAN.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 33

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

6.1 Golden Masters and Golden Snapshots

Virtual machines in a master pod should be thoroughly tested before pod cloning takes
place (full or linked). A master virtual machine that has been tested and deemed to be
production quality is called a golden master. Linked clones also require a pristine
snapshot that becomes the base disk for linked clones. This snapshot is called a golden
snapshot.

Keep in mind the following important rules about golden snapshots.

1. Updates to the golden snapshot only affect NEW clones (full or linked).

2. Updates to the golden snapshot do not affect EXISTING clones (full or linked).
Since snapshots operate on disk sectors and not individual files, this would lead
to disk corruption and is prevented by vSphere.

At some point, the VMs in your master pod will need to be updated, either in response
to a defect or to install new files. When this need arises, you must decide whether to
update existing cloned pods, or create them over again. Since linked clones can be
created very quickly, it may be easier to simply re-clone the pod rather than touch every
existing clone pod.

6.2 Creating a Master Pod

The first step in the pod cloning process is to create a master pod. At this time, the pod
type must contain only virtual machines if it is to be cloned using the pod cloning utility.
The following steps are used to create a master pod.

1. Create a new pod in NETLAB+ of the desired type. All of the pod VMs will initially
be set to ABSENT.
2. Build some virtual machines that will map to each remote PC position for the
pod type you are targeting.
a. Each virtual machine in the master pod should have its role set to master.
The role can be set when importing a virtual machine or cloning a virtual
machine. You can also change the role of an existing virtual machine to
master.
b. Whether you are storing VMs on an ESXi local disk or SAN, you should
assign the master to run on one of the ESXi hosts so software can be
installed on the VMs and the pod tested as a single functional unit.
3. Assign your master virtual machines to the new master pod (Section 5.5).
4. You may wish to use Pod Assigner at this point to prevent others from
scheduling the pod. You may assign the pod to an instructor account for this
purpose.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 34

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

5. Many NDG virtual pods support automatic networking. On the other hand, if
you are using a custom built pod or other pod that does not have automatic
networking support, you should make sure the virtual machines network
adapters are bound to the correct networks at this time.
6. Bring the pod online so that it can be tested.
7. Test the master pod.
a. Login to an instructor account (use the same account used with pod
assigner in step 3 if applicable).
b. Scheduled lab reservation in NETLAB+ and test the pod thoroughly
including testing all the virtual machines to assure proper configuration.
8. Linked clones in a master pod require a pristine snapshot that becomes the base
disk for your production linked clones. This snapshot is called a golden snapshot.
Once you are very confident that the virtual machines in the master pod are free
of defects, it is time to create a golden snapshot.
a. In most cases, you will want to power down every virtual machine before
taking the golden snapshot. You can do this from the NETLAB+ action tab
or from the vSphere client.
b. Take a snapshot on each master VM using a name such as
GOLDEN_SNAPSHOT. Currently, you must take snapshots using the
vSphere client.

Once each virtual machine in the master pod has a golden snapshot, linked
clones are possible.

6.3 Cloning a Virtual Machine Pod Using Linked Clones

In this section you will learn how clone a master virtual machine pod using linked clones.
Let’s suppose that the master pod is called pod MP1 and we want to create similar
cloned pods called CP1, CP2, CP3, etc. The first time you clone the master MP1 to
create cloned pod CP1, you will need to specify some parameters for each virtual
machine in CP1. NETLAB+ will keep track of the parameters used to clone CP1. You can
then instruct NETLAB+ to "create a CP2 pod like CP1" by cloning from CP1 instead of
MP1.

In our first example, we will make clone the master pod for the first time (MP1 to CP1).
The 3 virtual machines are master VMs with a golden snapshot. Recall that a golden
snapshot on master VM is required to create linked clones.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 35

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

If the clone button appears on the pod management screen, the pod can be cloned. If
the clone button does not appear, the pod is not eligible for cloning (i.e. it contains real
equipment, or contains VMs that do not use the NETLAB+ inventory).

1. We begin the pod cloning process by clicking the Clone button.

2. Select a numeric ID for the new pod and click Next.

3. Specify a unique descriptive name for the new pod and click Next.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 36

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

4. The pod cloning parameter form appears.

5. Verify that each source virtual machine is set to the correct master virtual
machine.
6. Verify that each source snapshot is set to the golden snapshot.
7. Set each clone type to Linked.
8. Set the role to Normal or Persistent. Use normal if the VMs will revert to a
snapshot to reset state. Use persistent if the VMs will retain state between lab
reservations.
9. Set each runtime host to the ESXi server where each VM will run. This should be
set to the same host containing the master VMs unless your VMs are located
on a SAN. If using a SAN, you can change the value as desired.
10. Set the datastore that will be used to store the new VMs. This datastore must be
accessible to the runtime host.
11. Verify that the Storage Allocation setting is set to On Demand.
12. Click Next to start the cloning process.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 37

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

6.4 Tasks to Perform After Pod Cloning

Here are some additional tasks that may be required after pod cloning.

• If you want to restrict access to the new pod, use the Pod Assignment utility.
This is often the case with persistent pods where you want to assign virtual
machines to a student or team for a long period of time.

• If the pod contains normal VMs that should revert to snapshot, take a snapshot
of each new VM using the vSphere client. Make sure each remote PC is set to
revert to this snapshot.

• If the virtual pod does not support automatic networking, be sure to bind each
VM to the proper port group using the vSphere client. If your VMs will revert to
a snapshot, be sure your snapshot is taken after this binding is made.

When you are finished with all tasks, do not forget to bring the pod online, otherwise it
will not appear in the scheduler.

6.5 Saving Time on Subsequent Pod Cloning

In our last example, we cloned the master pod (MP1) for the first time. We had to
change several parameters on the pod cloning form to produce the cloned pod (CP1).
You could produce a second and third pod (CP2 & CP3) by cloning MP1 repeatedly.
However, you will have to make the same form changes again and again.

A more efficient way to produce CP2 and CP3 is to clone pod CP1. When NETLAB+ sees
that CP1 is based on linked clones, it will assume you want to create a similar pod using
linked clones based on the same master VMs. The default values will be the same as
those you set for CP1, eliminating the need for changes. In most cases, you can click the
Clone Pod button without form changes and NETLAB+ will produce the correct result.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 38

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

6.6 Creating a Full Clone of a Virtual Machine Equipment Pod

You can also use the pod cloning utility to create new pods that are full clones of the
original. A full clone is an independent copy of a virtual machine that shares nothing
with the parent virtual machine after the cloning operation. Ongoing operation of a full
clone is entirely separate from the parent virtual machine.

The pod cloning procedure for full clones is similar to linked clones (see Section 6.3).
Only the VM cloning parameters will change.

1. Set each Clone Type to Full.

2. Specify a source snapshot to be used as the starting point of each cloned VM.
You may also select Current State to clone the current disk state of the parent
VM.
3. Specify the role of each new VM.
4. Select the runtime host for each new VM. Since you are making a full copy of
each VM, you are free to choose a different runtime host.
5. After selecting the runtime hosts, select the datastores where the new VMs will
reside.
6. Click the Clone Pod button.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 39

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

6.7 Creating Pods that Run on a Multiple VMware ESXi Hosts

Virtual machines are assigned to run on a specific ESXi host. Virtual machines in the
same pod should typically be assigned to the same host to simplify networking; this is
required for NDG pods that support automatic networking.

To leverage the compute power of multiple ESXi hosts, you can place pods on each host
so that the load will balance on average. When working with multiple ESXi hosts, your
pod cloning strategy will depend on whether your virtual machines are stored on an
ESXi host local disk or on a Storage Area Network (SAN). Local Disk Pod Cloning
Strategy. Refer to the diagram below. If your virtual machines are stored on an ESXi
server local disk, you will create one master pod (per pod type) on each ESXi host (MPA
and MPB). Production pods on each server will link to their respective master pod VMs.
Each host requires a master pod because Host A cannot access the disks of Host B, and
vice-versa.

The local disk pod cloning strategy is played by using the following moves.

1. Create master pod MPA on host A.

2. Create the first host A production pod CPA1 using linked clones (per Section 6.3).
3. Create additional host A production pods CPA2, CPA3, and so on. Use CPA1 as
the source pod to save time (per Section 6).
4. Test your production pods thoroughly on host A before moving on to Host B.
5. Create master pod MPB on host B by performing a full pod clone of master pod
MPA on host A. (per Section 6).
6. Create the first host B production pod CPB1 using linked clones (per Section 6.3).

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 40

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

7. Create additional host B production pods CPB2, CPB3, and so on. Use CPB1 as
the source pod to save time (per Section 6).

Storage Area Network Pod Cloning Strategy. Refer to the diagram below. Only one
master pod (per pod type) is required if your virtual machines are placed on a SAN.
Virtual machines in the production pods will link to the virtual machines in the master
pod, regardless of which ESXi host the virtual machines have been assigned to run on.
This is possible because each ESXi host has access to the storage area network (where
all virtual disks reside). The only difference between the production pods is the ESXi
host their virtual machines will run on.

The SAN pod cloning strategy is played using the following moves.

1. Create a master pod MPX. Assign it to Host A.

2. Create the first host A production pod CPA1 using linked clones (per Section 6.3).
3. Create additional host A production pods CPA2, CPA3, and so on. Use CPA1 as
the source pod to save time (per Section 6).
4. Create the first host B production pod CPB1 using linked clones (per Section 6.3).
This time, change each VM's Runtime Host to Host B.
5. Create additional host B production pods CPB2, CPB3, and so on. Use CPB1 as
the source pod to save time (per Section 6).

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 41

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

7 Virtual Machine Operations

This section describes common virtual machines operations and how they should be
performed in the NETLAB+ environment.

The following table summarizes which operations can currently be performed in

NETLAB+ and which operations must be performed using the vSphere client. This table
may change in future versions of NETLAB+.

Operation Perform Using Refer to:

"Creating Virtual
Machines from
Create Virtual Machines From Scratch vSphere Client
Scratch", Remote PC
Guide Volume 4
"Virtual Machine
Take Virtual Machine Snapshots vSphere Client Snapshots", Remote
PC Guide Volume 4
Create Port Groups for Real Equipment Pods vSphere Client 5.5.2
NETLAB+
Create Port Groups for NDG Virtual Machine Pods
(automatic)
8

Clone Individual VMs NETLAB+ 5.4

Clone Entire Virtual Machine Pods NETLAB+ 6

Delete All Virtual Machines in a Pod NETLAB+ 7.1

Delete Individual Virtual Machines NETLAB+ 7.2

Change Virtual Machine Name NETLAB+ 7.3

Change Virtual Machine Role NETLAB+ 7.4

"Migrating a Virtual
Machine to a
Migrate Virtual Machine to a Different ESXi Host vSphere Client Different ESXi Host",
Remote PC Guide
Volume 4

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 42

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

7.1 Delete All Virtual Machines in a Pod

If a pod contains virtual machines that reside in the inventory, you will have the option
to delete those virtual machines in one operation.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 43

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

You may choose one of four options. The option will apply to all VMs in the pod.

Delete Virtual Machines From

Option NETLAB+ vCenter Disk
Inventory Datacenter
Do not delete any VMs No No No

Remove VMs from NETLAB+ Inventory Yes No No

Remove VMs from NETLAB+ Inventory and Yes Yes No

datacenter

Remove VMs from NETLAB+ inventory, Yes Yes Yes

datacenter, AND delete unshared VM filed from
disk

Before deleting virtual machines, NETLAB+ will make sure the VMs are powered down.
Any automatic networks associated with the pod will also be deleted.

The option to delete virtual machines from disk cannot be undone.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 44

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

7.2 Deleting Individual Virtual Machines

Use NETLAB+ to delete a virtual machine that is registered in the NETLAB+ inventory.
This will remove the virtual machine from NETLAB+ and optionally from the vCenter
Datacenter and/or disk.

NETLAB+ will not allow an individual virtual machine to be deleted if any the following
conditions are true.

• The virtual machine is assigned to a pod. You must first set the remote PC for
which it is assigned to ABSENT to remove the association.

• A master virtual machine that is referenced by linked clones. This is to ensure

that there is an ongoing record of the parent/child relationship.

Do not use the vSphere client to delete a virtual machine that is registered in the
NETLAB+ inventory. This will cause the virtual machine to become orphaned.

Use the following procedure to delete an individual virtual machine.

1. From the administrator account, select Virtual Machine Infrastructure.

2. Select Virtual Machine Inventory.
3. Select the VM you wish to delete from the inventory.

4. Check the pod id and verify the VM is not assigned to a pod. NETLAB+ will not
proceed if the VM is assigned to a pod.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 45

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

5. Verify the number of children is 0. NETLAB+ will not proceed if this virtual
machine is the parent of linked virtual machine.
6. Click the Remove button.
7. Select the extent of the deletion. If you choose to delete unshared VM files from
disk (third option), the VM disk files are erased and cannot be restored.

8. Click OK to proceed.

7.3 Changing the Name of a Virtual Machine

Use NETLAB+ to change the name of a virtual machine that is registered in the NETLAB+
inventory. This will ensure that the virtual machine will be named the same in both
NETLAB+ and vCenter.

1. From the administrator account, select Virtual Machine Infrastructure.

2. Select Virtual Machine Inventory.
3. Select the VM you wish to rename from the inventory.
4. Click the Rename button.

5. Provide a new name for the virtual machine. This name must be unique in both
the NETLAB+ inventory and in vCenter.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 46

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

6. Click OK to complete the rename operation.

7.4 Changing the Role of a Virtual Machine

The role of a virtual machine is specific to NETLAB+ and changed using NETLAB+.

1. From the administrator account, select Virtual Machine Infrastructure.

2. Select Virtual Machine Inventory.
3. Select the VM whose role you wish to change from the inventory.
4. Click the Change Role button.

5. Select the new role of the virtual machine.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 47

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

If the new role is set to Template, the virtual machine will also be marked as a Template
in vCenter, and any ESXi host association will be lost. If the virtual machine is assigned
to a pod, NETLAB+ will not allow the role to be changed to Template.

6. If the current role is Template, you must also specify a target runtime host for
the virtual machine. This is because non-template VMs are associated with a
runtime host. The virtual machine will be set to run on the target host and will
no longer be marked as a template in vCenter.

7. Click OK to complete the role change.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 48

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

8 Using NDG Automated Pods

NDG provides many standard topologies that support special automation for virtual
machines. Pods using these topologies are created using the techniques described
earlier in this guide.

The automation described in this section requires VMware vCenter and the NETLAB+
Virtual Machine Inventory features as described in this guide.

8.1 NDG Real Equipment Topologies

As of NETLAB+ version 2015.R1.final, automatic networking and automatic remote

display setup is supported on the following topologies that are used to support current
curriculum offerings:

• Multi-purpose Academy Pod (MAP)

• Multi-purpose Academy Pod with ASA (MAP-ASA)
• IT Essentials Pod
• Cuatro Router Pod (CRP)
• Cuatro Switch Pod (CSP)
• Basic Router Pod Version 2 (BRPv2)
• Basic Switch Pod Version 2 (BSPv2)

When a pod is scheduled and lab reservation begins, the following automation takes
place:

• NETLAB+ will automatically calculate the control switch VLANs that are required
for the pod.
• NETLAB+ will automatically create VLAN based port groups on the virtual
machine host's inside virtual switch.
• NETLAB+ will bind the virtual network adapters of each VM to the correct port
group.
• NETLAB+ will configure remote display parameters automatically.

When the lab reservation is over, NETLAB+ will tear down the port groups created for
the pod to free resources on the host.

For automatic networking on real equipment pods, you must setup the inside virtual
switch on each ESXi host (refer to section, "Inside Network Configuration", Remote PC
Guide Series - Volume 2, Installation.
You must also provide the name of the virtual switch in the NETLAB+ virtual machine
host setup (Section 2). Automatic networking will not occur if these tasks are not
performed.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 49

Remote PC Guide Series - Volume 3
Configuring the NETLAB+ Virtual Machine Infrastructure

8.2 Setting the Local System ID When Using Multiple NETLAB+ Systems

If you have more than one NETLAB+ system, particularly if they access a common
VMware vCenter and/or ESXi host systems, it is necessary to set the System Local ID of
your NETLAB+ systems so that each NETLAB+ system is uniquely identified. This is
necessary in order to support pod automation as described in the previous section. If
you only have one NETLAB+ system, using default value '001' is sufficient.

System Wide Virtualization Settings are accessed from the Virtual Machine
Infrastructure administrator option.

11/21/2016 Copyright © 2016 Network Development Group, Inc. www.netdevgroup.com Page 50