As part of the Basic vSphere 6 lab setup article, we are now with the VMware Update Manager (VUM) setup article. The timing is good since yesterday Update 1 dropped. And that is big since – among many reasons – it has the VAMI back, and it provides full configuration and use of VUM in the Web Client. So pretty exciting.
However, this article is about installing and configuring vSphere ESXi 6.00 which is part of the series I am doing but will also help more of you. I will do another article to show you how to upgrade your hosts to 6.0 U1 and William Lam has a great article on updating your vC 6.0 appliance to 6.0 U1. It is very good he did the article as I had trouble and had not found the patch ISO for the appliance until I saw the URL in his article!
So lets get started.
Things to get ready
Here is a list of things to do before we actually starting to install VUM.
- If using External database – use the info here to help. You will need to create a 32-bit ODBC connection and a database. Maybe even firewall rules. But check out the referenced article.
- If using Embedded database – nothing database to prepare. It will be dealt with by the install. I will in fact be using the Embedded database option since I am in a small portion of my lab for quick testing.
- If using the Embedded database option (on Win2K12 primarily) you must not be using .NET Framework 4.0. I am using 4.5 and I hope that is not an issue. I will update here with yea or nay as appropriate – update – no issue.
- If using the Embedded database you must have Microsoft Windows Installer 4.5 installed – find it here. From looking at the download files I am going to guess that Win2K12 doesn’t need this and in fact already has it. We will see – update – nothing to worry about.
- You should check out the release notes, bits, and docs (you will need to change to 6.00a on this page for the right docs). We also need local access to the bits. I am working with vSphere 6.00b in this article. Which is, oddly enough, 6.00a for VUM. There was no updated VUM in 6.00b. But my vC and ESXi is.
- As part of the configuration we will set up an ESXi 6.0 baseline so make sure you have that ISO handy. BTW, you could use it for 6.0U1 too as the process is the same – although in 6.0U1 vCenter you will have full access to VUM controls in the Web Client. Since we are in 6.0 we will use the VMware Client – often referred to by many as the C# client.
- Windows 2012 server VM fully patched and ready to go. On the domain but not a domain controller. I also suggest you have a separate disk on this VM to store patches / updates. I do that and it is 80 GB in size.
- vSphere 6 licenses for hosts are not the same as vSphere 5 licenses! So be ready for that when done.
In this section we will get VUM install and working. I have the vCenter 6.00b bits local to where I am working and ready to go.
- So we start by double+clicking on autorun.exe.
- Once we start autorun, we will be alerted about running it from the network and you will see the main screen.
- We can see in the image above the thing to click on. Once we click on Server in the VUM section we get to make some choices.
- We are doing embedded database so we need to select that and start the process with the install button.
- SQL will install. Not much to watch or do.
- VUM will start. The first pause gets you this.
- I don’t like to have things updated or downloaded before I configure things. So I deselect this option and continue.
- On the next screen we need to configure our connection with vC. I like to use a service account for this.
- Important to note that the IP address shown for the vC is in fact not your vC. It will need to be corrected and the service account info added.
- You can see above what I configured. Next up we see something different.
- Normally there is no need to make changes here.
- On our next screen we select our path. I like to dump the patches in a different disk structure so not to impact drive c:.
- So on my system the downloading patches location with have same name exactly but be on drive G.
- You will be alerted to the fact your patch downloading location is smaller then 120 GB. I have never used 120 GB but I have recently started to use 80 GB.
- You are prompted to push the Finish button. Which I like to do and so I did.
We now have VUM installed but not useful yet. You can log out of the VUM server as we will work elsewhere now.
Adding the VUM Plug-in to the C# client
This will allow us to configure VUM. In 6.0 U1 you will be able to do all the configuration without this setup in the vSphere Web Client – which makes my day!
- Start your vSphere Client – AKA C# .
- Next you select Plug-ins \ Manage Plus-ins
- Now scroll down and look for Available Plug-ins
- You are looking for the Download and Install as seen above in the middle of the image.
- Once you push Download you will be prompted to run a file.
- Select Run, and it won’t take long. Accept the EULA and Install.
- After it finishes you will be prompted to accept a SSL certificate for the vC. It is OK to accept it and in fact necessary.
- Once you accept the certificate you should hit close.
You are good now to start the next step.
Configuration of VUM
We start in the C# client again. We are now going to configure the behavior of VUM so it works best for us (me, you and them too).
- Locate the Update Manager plug-in in the Solutions area.
- We are going to start on the Configuration tab.
- The first section is Network Connectivity and we don’t make any changes there normally.
- The next section is Download settings and again normally no changes. If you have a local shared repository, or need to set proxy settings that would happen here.
- In the Download Schedule screen I like to change it to an early morning download time and add my email address so I know if anything comes down. That way when I sit down at work I see if there is outstanding patches or not.
- On the next screen – Notification Check Schedule – you absolutely should put your email in. Or your team email, or your alerts email so that if VMware recalls a patch you will know about it. This is certainly not a common occurrence but if it even happens once you want to know about it.
- In the next screen – Virtual Machine Settings – I like to disable the snapshot option.
- In the next screen – ESX Host / Cluster Settings I make a number of important changes.
- I use the default settings but also I like to select the three I have pointed out above (temporarily disable any removable media, HA, and FT). After you make any changes here make sure to hit the Apply button in the bottom right. BTW, if you are working in a new cluster with very few or no VMs, I suggest you use the Enable parallel remediation as it can greatly speed things up.
That is the end of the configuration of VUM.
Protecting our cluster
I am referring here to attaching baselines to our cluster so we will know when hosts are out of compliance but also have something to organize our patching around.
- We should be in the C# client, and move the to the Hosts and Clusters view,
- Select the cluster,
- And change to the Update Manager tab.
- We will start with using the Attach blue button in the top right. We will see a new dialog pop up.
- We can see that we have two Patch Baselines, and no Extension or Upgrade Baselines. Nor do we have any Baseline Groups. BTW, you would use an Extension Baseline for things like PernixData FVP, and Upgrade Baselines for things like the next vSphere version – like vSphere 6.0 U1.
- We are going to select both Critical and Non-Critical Host Patches so they are both attached to our cluster. These are dynamic baselines so they will always be current. What that means is early each morning (as per our Download Schedule we defined above) VUM will reach out to VMware and see if there is any new patches to download and download if necessary. Any of those download patches that fit either Critical or Non-Critical will be added automatically to the baselines.
- Once they are attached you can use the Scan button if you want to see if the hosts are compliant or not.
Suggestion: I would suggest here that you create a Scheduled Task of Schedule a Scan and set it to scan your ESXi hosts in your cluster. Set this task to run every day an hour after your VUM download time. This means you will be notified when patches are downloaded but a short time later you will be able to look at hosts and see if they are Compliant or not. Just in case, find Scheduled Tasks on the Home page if you are using the C# client, or on the Manage tab for the vC if you are working in the Web Client.
Create our own baseline
We have VUM installed, configured, and even have two baselines connected to our cluster. Each day, an hour after we check for patches to download, we do a scan of our cluster so we can see if our hosts are compliant or not. Nice. But, I have a vSphere 6.00b lab where my hosts are still some silly old version of 5.5. So I want to upgrade them, which means I need an baseline of v6.00b and then I can use that baseline to see who is at 6.00b already, and if necessary use it to remediate.
We need to have our vSphere 6.00b ESXi ISO handy. BTW, if you had already upgraded your VCSA from 6.00b to 6.00 U1 you could follow the process here with your 6.00 U1 ISO. Although it would be more fun in the vSphere Web Client.
We start in the C# client.
- We select Update Manager.
- We change to the ESXi Images tab.
- We use the blue button on the right to load our ESXi image.
- When we hit Next – after selecting our image, we will get a trust SSL message to ignore so select Ignore.
- Once the upload is finished you will see an informative screen.
- Now we can create a baseline on the next screen which is quite handy.
- Now we attach it to the cluster, just like we did for the Critical and Non-Critical baselines above.
- If we do a scan now we will see something different.
We can see how our hosts are compliant for patches but not for upgrades.
So this is the fun part. I am going to start the remediate and then go pick out the wine for tonight. And yet, no outages for anyone. I do really like VUM a lot. While at VMware I got to work with the team on replacing VUM with something new and more powerful and I spent a lot of time with them to make sure it was everything it could be. But alas, that was not to be.
In vSphere 6 you could not remediate in the vSphere Web Client – you could scan or attach. That has changed in U1 thank goodness. I can’t wait to be there. So lets start in the vSphere Client.
- Change to the Hosts and Clusters view.
- Change to the cluster,
- And now change to the Update Manager tab.
- Now look to the bottom right for the Remediate button.
- In the next screen you do not always need to change things. You can select baselines, and hosts to match your needs.
- For me I need to select Upgrade Baselines, and the proper baseline.
- Next we accept an EULA.
- In the next screen we confirm the 6.x upgrade. Generally you do not need to select the checkbox about ignoring unsupported hardware if you are using tier 1 or even tier 2 hardware. In my home lab I did not select this and my tier 1 / tier 2 hosts are fine and my clone boxes – 2 of them, are not usable. I have not had time to fix them either.
- Next screen is for scheduling but I like to do it now!
- After scheduling comes the Host Remediation Options. They should be set OK as we did do that earlier in VUM setup.
- After this we are in Cluster Remediation Options, and again it should be OK as we took care of that in VUM setup. If I have an empty cluster I will often use the Enable parallel remediation here as it significantly speeds things up.
- Now we confirm and it all starts.
- You can see how it is going in a variety of places.
Thing will take a little while. I am going to go look for the wine for tonight. So I am back, and I see that it has not finished. Plus no hosts have been done. So I took a look at the Home \ Update Manager \ Events and see see something interesting.
I see that the hosts could not get into maintenance mode. That is almost always due to vMotion issues. I quickly check the host networking and confirm that the IP is correct on both servers. Next thing I do is try and do a manual migrate. It fails and I get the message about issues on destination and of course it is that the port is not configured for vMotion. So easy to fix. And I did this fast, and manually vMotioned the VMs off the host and the VUM action continued. So we should be OK I think. I wasn’t. After 20 minutes of nothing I started the Remediation again.
Now you know why one of my tests I did before I ever turned an environment over to customers was a vMotion of several VMs between each and every host. For some odd reason I called it – unofficially – walking the monkey. And the monkey had to visit each host. It was better for me to catch vMotion errors before the customers did! But I did not do that this time. To my regret.
Another issue I have seen a number of times is that remediation will fail with an incompatible host message. This was normally due to no restart of a host after an upgrade / update, and now doing a VUM. The solution was to do a manual restart and try the VUM again and it would normally work.
Suggestion: when you have a bunch of hosts, for me around 4 or so I would stage patches. The Stage button is right beside the Remediate button. It is not something with an outage but it gets the bits organized for a faster update.
While everything is working, the fact is: it is really slow.
If you check out the Host Events after it has come up – after the upgrade, you will be surprised at all the stuff. There is a lot of interesting things like VSAN NIC added, and a lot of firewall changes and a lot more. It doesn’t like my coredump space so I will need to fix that soon with remote coredump I think.
So my hosts are back. They are showing vSphere 6.0 and in the Update Manager area I see this.
On the hosts themselves I see the following.
So pretty happy. And don’t forget, you will need to use vSphere 6 licenses for your hosts.
Thanks for reading! Questions or comments area always welcome.
I hope – early next week – to do a lab upgrade article for the vSphere 6.00 Update 1 process.
=== END ===