It has once more come time to upgrade my hosts with security patches and I have run into one more, but easily worked around issue. Some VMs do not migrate or power-off when entering maintenance mode. These VMs include vShield per host appliances, and surprisingly vCops.

I have been using vCops Advanced since v1.0, but wanted to get more of an experience with vCops Enterprise. Specifically, the most recent GA version 5. Installing all the different components of vCops Enterprise is not a task for the faint of heart and there are so many pre-requisites, that it becomes increasing more difficult to keep everything going. The easiest component to install and configure was vCops 5, itself. With vCenter Infrastructure Navigator a close second, but VMware Configuration Manager, has even more dependencies and due to these, it is not so simple to install. Perhaps, this is why there is no trial available on VMware’s website. Even so, with good planning all these tools can be installed and made available.

Remediation of vSphere patches when vCops and vShield is in use poses several problems. These problems came to be as I prepared myself to apply the most recent set of updates. Actually my first updates since moving to vSphere 5. The problems can be surmised as two VMware Update Manager failures.

I have been running VMware Data Recovery (VDR) through its paces for quite a while now and while it works, I am not sold on it yet. I have had way too many problems related to the target datastore. Specifically, a continual failed integrity check. Everything ran fine for a while and then poof, a failure, and just when I needed it the most. It has been a very frustrating state of affairs. But I finally found a solution that is working for now. In the meantime I will be running Veeam Backup and Replication, Quest vRanger, PHD Virtual, and several other backup tools through their paces.

When using the RHEL scsi-target-utils, there is some special mojo needed when connecting to vSphere 5 (perhaps any version of vSphere). Unlike the iSCSI Enterprise Target (IET), the new service makes use of modern iSCSI targeting techniques, and these did not work as expected with vSphere out of the box. For a few days, I was confused as to what was happening, but not anymore, so now my iSCSI server for my vSphere Environment is back in running shape after its hardware upgrade, new operating system, and upgraded disk drives.

This is the week end I move all my existing hosts to vSphere 5, to make way for some other work. Actually, I will migrate 2 of 3 hosts, while leaving one host at vSphere 4, more later on why. While Host Profiles has greatly improved, it is still not sufficient when updating and migrating nodes that use physical virtual NIC devices such as HP Flex-10. Why? Because they want to know the MAC Address when you apply the profile. This is a chicken and the egg sort of approach to Host Profiles.