After my upgrade to vCenter 5.5, there were still a few things that needed to be tweaked to fully upgrade my environment. I was in a working state, but now I needed to plug in all the bells and whistles I normally use, such as Host Profiles, VIN, and HP Insight Control, as well as vCenter Log Insight (which is a fairly handy troubleshooting tool). All of these are relatively little things, but they take a fair amount of effort to get right. So, where to begin? By ensuring that I can manipulate the vSphere consoles without actually logging in to each of the consoles. I did not need this for some of the bells and whistles, but I do need it for other things.
I have written about a few approaches to this when using RHEL5 or RHEL6 in the past, but what I present now is a recipe that will work for both and, most likely, any other form of Linux. Now, you can use a Windows version of the vCLI, but I prefer Linux. Here are the steps:
Download VMware vSphere Perl SDK
$ tar -xzf VMware-vSphere-Perl-SDK-5.*.x86_64.tar.gz
$ sudo yum -y install gcc openssl-devel libxml2-devel expat-devel curl-devel libxslt-devel pcre-devel swig python-devel
# Include ALL dependencies for each CPAN module
$ sudo perl -MCPAN -e shell
cpan> install SOAP::Lite <=== Important to include all dependencies
cpan> install HTML::Parser
cpan> install URI
cpan> force install Compress::Zlib <=== Gotta override what is there already
cpan> install Spreadsheet::ParseExcel
cpan> install Spreadsheet::XLSX
cpan> install Text::Iconv
cpan> install Scalar::Util
cpan> install XML::Dumper
cpan> exit
$ cat << EOF >> t.sh
export http_proxy=””
export ftp_proxy=””
./vmware-install.pl
EOF
$ sudo sh -x t.sh
…
This vSphere CLI installer includes precompiled Perl modules for RHEL.
Answering yes will install the precompiled modules, and answering no will
install from CPAN.
Do you want to install precompiled Perl modules for RHEL?
[yes] no <==== THIS IS THE IMPORTANT BIT
BUT only appears if using vSphere SDK 5.5
…
Now that I have a working vCLI and Perl SDK environment for vSphere 5.5, I can continue my development of tools for use with vSphere and vCenter as well as manipulate my hosts without needing to access the command line. The next step is to allow my user to access vCenter without needing to type the password on the command line every time (which is a security issue). In addition, you need to track any access to the SDK within vCenter.
# fill out credstore for Perl usage
$ /usr/lib/vmware-vcli/apps/general/credstore_admin.pl add -s vCenterServer -u MyUser -p vCenterUserPassword
Now I am ready to begin with my next set of upgrade steps. I did the above within a virtual machine created just for the purpose of running the vCLI and my special tools, but another option is to use the VMware Management Appliance (vMA) instead, which is installed as an OVA.
Here are my followup steps to my upgrade of vCenter:
Step 1, Upgrade HP Insight Control
In order for HP Insight Control to properly talk to vCenter v5.5, you should upgrade to HP Insight Control v7.2.0 Update 2. You should also ensure that you have a user within vCenter that is dedicated to HP SIM (HP Insight Control).
Step 2, Upgrade HP Insight Control for vCenter
With the new version of HP Insight Control, there is a new version of Insight Control for vCenter. If you upgrade, all your existing settings will be kept.
Step 3, Reinstall Virtual Infrastructure Navigator
There is a new version of VIN for vSphere 5.5, and it is best to use the latest. While this is only available with the most recent versions of vCloud Suite, I find it very useful.
Step 4, Install vCenter Log Insight
This is a relatively new tool that has generated a lot of press lately, so I decided to install it in my environment. It works very well but has its own issues. Specifically, if your browser time and your LogInsight appliance times do not match (for instance, if they are in different time zones), you need to work within the LogInsight appliance time zone. So, if your browser is EST, and LogInsight is CST, elect to view everything for the last hour, or else you will miss most of the records. This is one reason you want consistent time zones across all your systems.
Step 5, Tell ESXi hosts to send log data to Log Insight
This is one time you need to use vCLI, which allows you to talk to each ESXi host by authenticating to vCenter. This helps avoid the need to directly connect to a host (a security improvement) and logs all commands. For more details, please look at KB Article KB2003322. I used the following command across all of my hosts. You can also query each host using the SDK.
for x in host1 host2 host3 ... host4 do esxcli -s vCenterServer -u MyUser system syslog config set --loghost='udp://w.x.y.z:514' esxcli -s vCenterServer -u MyUser system syslog reload doneNot only does this command point your vSphere server logs to w.x.y.z, but it also opens up the firewall on each vSphere server to allow the communication. In my case, w.x.y.z points to my vCenter LogInsight appliance.
Step 6:Mark SSD as SSD
Using the vCLI and the documented instructions, I added a claim rule to my SSD-based storage, causing SSD disks to show up as SSD. Otherwise, they would not, due to the age of the SAS controller in use on the blade.
Step 7: Re-enable Host Profiles
Host Profiles has caused all sorts of issues, specifically around storage, which were solved with the assistance of KB2002488 and Virtualcloudz. Well, sort of solved. One of my systems has a local SSD. This seems to confuse the SATP claim rules, which to enable SSD does not apply to the host profile and causes any number of errors. I have yet to find a solution that does not require me to disable the entire Storage Host Profile, even those bits such as FCOE and iSCSI that do not apply to the local disks.
To fix this issue, I removed the conflicting claim rules from the host, per the additional information in KB2013188. Between the removal of the claim rules and the fixes for SATP outlined above, all of my storage issues within host profiles went away.
Now comes the fun part: a rolling application of the host profile, which starts with placing a node into Maintenance mode and applying the profile to the node. You may have to apply the profile a few times for all the elements to be properly updated, as the iSCSI adapter changes are not made the first time around. iSCSI is configured on my nodes but not actually in use.
That last node with the change to the SSD claim rules required me to first disable all storage in the host profile and then apply all other changes. This failed due to an issue with Option ScratchConfig.ConfiguredScratchLocation setting within the host profile. It caused the words “Error: A specified parameter was not correct.” and a single quote to appear on the next line. This is perplexing, as all the other hosts have the exact same setting, “use default.” In the end, I also disabled this host profile rule, as I could not figure out why it was considered wrong.
Step 8: Update to the Latest Set of Patches
This step is not strictly needed, as we will be migrating to vSphere 5.5; however, that may be a bit down the road, so an upgrade would be in keeping with security and maintenance policies. I accomplish this by staging the patches and then remediating them as a rolling upgrade. However, since I have admission control on, I either need to disable it or to adjust the admission control to allow the use of the VMware Upgrade Manager. With my small environment, I chose to disable it.
A quick note: Inside the vSphere Web Client, you can scan and attach Upgrade Manager baselines, but you need the .NET client to remediate any changes.
Step 9: Deploy the Latest vMA
Although I built my own, I still like to use VMware’s vMA from time to time. This also helps me to assist my own customers. You will need first to unzip the image in order to unpack the OVF and then do the import into vCenter. In addition, when you start the vMA, it will ignore any IP settings used when deploying the OVF. You will have to enter them again; just go to the console of the VM and follow the instructions. Lastly, I add a non-administrative user to the vMA so that I can run the commands as the same user on all systems.
Finally, my vCloud Suite environment is in a good state. All of the important features work, and I seem to be missing just two items: vCloud Director and an upgrade of vSphere to 5.5. I am at a crux: should I deploy vCloud Director or vCAC? I am leaning toward vCAC. Most of the upgrade process for any environment is primarily the upgrade of the virtual management ecosystem, with the upgrade of vSphere being a time-consuming and important aspect but generally not a very challenging task.
Get all of your management ecosystem components upgraded before you tackle vSphere, as doing so will ensure that you have the right foundation upon which to smoothly upgrade your vSphere hosts.
