Labs 11, 12, and 13

Lab 11

This lab was all about templates and cloning. The first thing I had to do was convert one of my VMs to a template. This would be the basis for most of the machines I'll be making down the line. All the tasks went smoothly.

There was some differences with what the lab said and what I had to do, such as datastores. In the lab guide it assumes you have two local datastores for each ESXi host, but I have only set up one. It shouldn't affect the labs so I just used the single datastore, but if needed I can easily create new datastores and migrate the machines.

Cloning live machines, powered off machines, templates, or templates from a content library work almost the same. A template is just a machine disk and configuration, but it isn't allocated resources. A powered off machine might not be using resources, but it can still be allocated host resources. Using a content library to store templates can be very useful. It allows you to share templates between sites or easily distribute templates to etc.

Template:

Creating a VM Customization Specification:


Deploying a machine from a template:


Successful clone and config of L2-Win7_01-2-RL (Equivalent to VM1-2 in the lab guide)


Deploying a machine from a content library:


Cloning from a live machine:

Lab 12

This lab involved Modifying virtual machines. I had to complete various tasks for changing disk allocation, memory allocation, and renaming.

First off, I had to change the size of a VMDK. It's interesting, because windows does not immediately use the additional storage. Any size addition, or new disks added to a VM must be formatted using a partition manager in the VM itself. In my case I had to expand the size of the C drive partition to fill the new disk size.

Before expansion:

After expansion:

Next I had to adjust the memory allocation of  a VM. It must be noted that Memory and CPU allocation cannot be changed while the machine is on; these options are greyed out until the machine is off. Most OSs would not take such a change very well, because in a physical machine replacing ram or CPU in real time can only happen on high end server hardware with supporting software. What you can change however is the priority and reservation of resources. You could allocate 16GB of memory to a VM and reserve 8GB, so the VM would always be guaranteed 8GB of memory even if it was only using 4GB, then the unreserved memory would be free for use by other VMs. 

Adjusting memory to 2048MB as specified by the lab guide:

For this next task I had to change the name of a VM. You might think this is a trivial task, but there is a very important point to note: the folder for the VM doesn't update to the new name. This can make big problems if you make a bunch of VMs all called 'New Virtual Machine', then rename them to what you use them for. If you need to delete or copy a VM from a datastore you won't be able to tell which VM is which. Because of this, it is important to name VMs properly the first time.

If needed, one way to get the folder and file names right is to clone the VM and name the clone properly, then delete the incorrectly named VM. 

Renamed Hot-Clone to L2-Win7_02-3-RL:

Folder retains name:

Lastly for this lab, I had to add a RDM(Raw Device Map) disk. Normally a disk for a VM is stored as a file on a datastore; with RDM, the VM connects directly to the LUN with lower latency rather than using a virtual disk within a datastore. Connecting to a lun with RDM is higher performance because there are less layers that the VM has to go through to use the storage.

Lab 13

In this lab I had to set up vMotion and migrate various VMs. On the networking side I had vMotion mostly set up and setting up the first host was easy. The second host had issues though. For some reason I was unable to add a new vmkernel adaptor and after restarting the host I was unable to network with it at all. 

After going through the DCUI, I found an option to reset the networking entirely back to default. I managed to connect to the host after that, and it was a matter of reconfiguring all the port groups, vswitches, and vmkernel adaptors as required before I was able to get everything running properly. 

I was able to then add my networking for vMotion and continue with the lab. 

vMotion can be used to manually migrate VMs in three different ways. You can:

• Migrate compute resource. This option changes what host or cluster the the VM will be using for CPU and memory resources. This is very fast as it just copies the live memory of the a VM to a different host.
• Migrate storage. This option copies the VM's files to a different datastore or datastore cluster
• Migrate storage AND compute resource. This option just allows you to set the two previous options at the same time, though you can chose whether vMotion moves the storage or the compute resource first

I completed all types of migration successfully.

migrate storage

Setting up networking for compute resource migration

Compute resource migration with ping latency:

Compute resource migration for second VM:

Compute resource and storage migration: