Posts

Showing posts from November, 2018

Lab 21 FINAL!

Image
Lab 21 Finally I'm up to my final lab! It's taken many hours to get to this point, so I'm glad that I have finally arrived! Right, this lab was all about using the vSphere Update Manager to update a host.  First off, I needed to get the environment ready for the lab, so I enabled automatic DRS, and I checked that there were no reservations for any resources. Once that was all sorted out, I set up the vSphere Update Manager. Automatic DRS enabled: While setting up the update manager, the lab tells you to import a specific patch file. Since I have a different patch level ESXi host, and don't have that patch file, I decided to just download patches directly from the internet since I have internet access in my network. Actually, at first I just downloaded the patch definitions, downloading the actual patches will happen when required. Downloaded patch definitions: Next I created a baseline for the host, then I attached the baseline to the esxi02...

Lab 20

Image
Lab 20 For this lab I learned how to use a vSphere DRS cluster. First off I created a load imbalance. I had to play with the resource allocations and cpu load generator strength to get it to detect enough of a load unbalance. If the ESXi host is not stressed enough it doesn't seem to want to balance the load. Once that was all working, I got a DRS recommendation, then I applied the recommendation to balance the load. Imbalanced load and migration automation settings:   Imbalanced CPU usage: Recommendation: Applying the recommendation: 02-1 and 02-2 machines now on different hosts. Load is balanced: Next, I played with affinity rules. These rules allow you to make specific VMs stick together, or have VMs have a higher affinity with a specific host or resource pool. In my case I created a VM-VM affinity rule which makes specific VMs stick together on the same host is possible. Creating the rule: DRS showing a recommendation because of the affinity rule:...

Labs 18 and 19

Image
Lab 18 This lab covered alarms in vSphere. Alarms can be set to trigger from a variety of different events and can trigger events themselves. You can set alarms on specific machines, or any other object in vSphere such as a datacenter or resource group. In the case of this lab, I first created an alarm on one of my VMs that that would trigger a warning if the CPU usage went over a certain level. It's very easy to change what different levels of warning you want to trigger, and at what CPU usage level. I then set an action so that the VM would be suspended when the alarm is triggered. The next alarm I created was on the Datacenter. It was set to trigger when a VM with the specified name was suspended. I tested if you could enter a partial name for a VM to trigger for any VM starting with that name, but I figured out that the name has to be an exact match to a VM. To trigger for multiple VMs, you could instead put the VMs in a resource pool and set the alarm to check if the ...

Labs 15, 16, and 17

Image
Lab 15 For this lab I had to work with resource pools. Resource pools are used to share out resources to VMs. If all VMs are using max resources, and half are in a resource pool with less CPU shares, that half will have less performance available than in a pool with more shares. Resource pools could be used to guarantee that critical machines will have a specific amount of resources available if resources are competed. To simulate CPU load in the virtual machines, I needed a load generator. The lab assumes you have lab files with a load generator, but I had to download one myself. I had set up internet in my network, so I just give my VMs IPs and I could access the internet to download the load generator. VM using CPU resources: Performance difference between resource pools. Look at the CPU usage: If you set the amount of shares to be more similar for the resource pools, the cpu usage gets closer together for the VMs. Lab 16 In this lab I looked at vApps....

Lab 14

Image
Lab 14 This lab had a number of tasks that involved VM registering and snapshots. I had worked with these features before so it did not take long to get through this lab. Deleting VMs When deleting a VM you need to be careful about how you do it.  Deleting from inventory merely removes the VM from the list of VMs in 'VMs and Templates'. It leaves all the VM files intact. To get this machine back on the list you just find it in the datastore, and register the VM using the VMX file. Deleting from disk removes the VM from the inventory, and it also removes all the VM files from the storage. Registering a machine after deleting from inventory: Deleting from disk: Deleting other VM from disk: Managing Snapshots When taking snapshots, you can chose to save the VM's memory or not. If you save the memory in the snapshot, the snapshot will take longer to make and it will take up more space, but if you revert to it, the machine will revert to a booted mac...