Creating a training setup with PowerCLI and vmware ESXi 5.5

Опубликовано: 28 Июнь 2026
на канале: vmutils
1,402
2

NARRATION:

In this video I am going to show how to use a set of scripts in order to provision in minutes, the infrastructure to support a training session where each student needs to use a set of vms, which are exactly the same for every one, while keeping them isolated from each other but accessible for each student.


I will:
Create the master vapp
Create linked clone vapps from that master vapp
Explain one way to provide external connectivity to the vapps
Rebalance the vapps among any number of datastores
And finally I will provide some explanations about the networking inside the Pods and the affinity rules applied to them.


First I will create a vapp with all the required vms and then power them down and take a snapshot on each one.


Note that the Gateway vm has 2 nics. Later we will use that vm to provide external connectivity to all our classrooms, for this and the following weeks.


Now I will create 8 linked clone pods. I take 8 as the maximum number of students I may have in any given training.


As this is the first time I created linked clones of the Gateway vms, I will go into each one, and manually configure the networking settings.

The networking settings could be anything that fits your needs.

In my case I will first connect the second nic of all of them to a portgroup that has external connectivity. You can do it manually or with power CLI.

Then I would configure the OS of each Gateway vm to:
act as a NAT plus DHCP on the left side
have a static IP on the right side
and to do IP forwarding to a specific IP within the lan on the left side

In this way,
vms inside the pod can reach the internet sharing the Gateway static IP
vms inside the pod have a DHCP server
my students can get inside the Pod by doing RDP or VNC to the external IP, which would be forwarded to a specific IP inside the pod.



Once these Gateway vms are set up, I can take them in and out of the Pods easily with another script.


To make it convenient for the following classes, I will leave them out of the pods, before I distribute the heavy vms. I do that because I want them to stay on the shared storage.


As you can see, I have 4 hosts.

All of them are connected to a shared NFS, and each one of them also has a local datastore.


To improve the performance of the vms for my students, I want to distribute the pods among the available local datastores. In this way, when the linked clones write on their virtual disks, they write on the local datastores, but when they read from the parent vm, they do it from the NFS.


I will do that with a 3rd script.

Now that the heavy vms are spread across the local datastores, I will insert the Gateway vms back to the pods.

As you can see, they are also inserted into the affinity rules of each pod.

And the portgroup settings are preserved. That is why I can reuse them every week.




If you wonder how long all this takes ...

Creating 8 linked clone vapps with 4 vms each, that is 32 vms, took 8 minutes.

Rebalancing 24 linked clone vms across 4 different datastores took 7 minutes.

Extracting or inserting 8 Gateway vms took 40 seconds.



You can put these 3 commands on a file and run it every time you want to deploy the vms to support a training session.



Now, for those interested, I will describe in more detail the networking associated with these Pods.

When I created the pods, I specified that I wanted to use the cluster as workspace.

The script will then create an isolated standard virtual switch on each host in the cluster, and will also create a portgroup with a unique V-lan for each one of the pods. That means that I can run any pod in any host in the cluster, knowing that their traffic will be isolated from the other pods. All this is happening inside the ESXi hosts, so you don't need special network equipment or distributed switches.

However, for this to work well, the vms in each pod must run on the same host, as they are standard virtual switches, not distributed switches.

To make sure that happens, each pod has a DRS affinity rule, that makes sure that when you power on the vapp, all the vms will run on the same host.


And when the training session is over, you can extract the gateway vms from the pods, and remove the linked clone Pods.


Thanks for watching.