So with vSphere 6.5 now GA, I decided to upgrade my lab to vSphere 6.5. In my environment, I use a vCenter with an external Platform Services Controller (PSC). So as part of the upgrade, I have to upgrade the PSC first.
When you run the UI installer provided within the VCSA 6.5 Appliance ISO, you have the option to “Upgrade” a vCenter Server Appliance or a Platform Services Controller. The installer detects the component that you are trying to upgrade and prompts for settings appropriate to that upgrade.
While VMware vRealize Operations Manager makes use of a Gemfire database and vRealize Hyperic makes use of vPostgress, VMware vRealize Log Insight makes use of Cassandra. You might wonder why knowing that even matters. Well, as I’ve seen again this week, the database engine that drives each of these products essentially dictates the design and deployment of their environments and their limitations.
This week, we had a situation where our newly deployed Log Insight cluster wasn’t performing. In fact it was so bad, that it took 20 – 30 minutes to simply log into the admin interface. Yet the CPU and Memory usage counters for each of the appliances weren’t even being tickled. It was a strange issue for sure, and by 5pm on Monday 31st of August, we were in the process of logging a P1 call with VMware support.
After updating my View environment to version 5.2, I noticed that my PowerCLI scripts that I run on the View Connection Server keep failing. After looking into the issue I found that each script execution fails when trying to load the snap-in for View PowerCLI into PowerShell with the following error:
"Add-PSSnapin : Cannot load Windows PowerShell snap-in VMware.View.Broker because of the following error: The Windows PowerShell snap-in module C:\Program Files\VMware\VMware View\Server\bin\PowershellServicesCmdlets.dll does not required Windows PowerShell snap-in strong name PowershellServiceCmdLets, Version=188.8.131.5215, Culture=neutral, PublicJeyToken=null"
To resolve the issue, the new PowershellServiceCmdlets.dll file installed during the View Connection Server update, needs to be registered with Windows PowerShell .
To register the file, open a new Windows PowerShell prompt and run the following script:
“C:\Program Files\VMware\VMware View\Server\Extras\PowerShell\add-snapin.ps1”
When working on a Linux VM via the VMware Remote Console over a WAN or slow link, the keystrokes sent to the console might end up reppeating. In order to avoind this, perform the following steps:
1. Power down the VM
2. Add the following line to the VMX file (can also be done by editing the Advanced VM settings using the vSphere Client):
keyboard.typematicMinDelay = "2000000"
3. Save the VMX file
4. Power on the VM.
I decided to post this as I keep on forgetting what the fix is. Now I'll know where to find it in the future without having to go to Google ;-)
In VMware ESX you can use the vimsh command from the command line in order to retrieve CDP information. With the release of ESXi 4.1, the vimsh command is not included. However there is still a way to retrieve CDP informtation via the CLI. Instead of using vimsh, you simply use vim-cmd. The path to the utility is /bin/vim-cmd.
I have to write this down as I'm sure I'll come across this issue again in the future. Today I had to install ESXi 4.1 on a ProLiant BL465C G7 blade server. This turned out to be problematic to say the least. It turns our that the native ISO imaged downloaded from the VMware website does not include all of the drivers required for ProLiant G7 blades. Anyway, as I had a very busy day, I really didn't have time to try and figure this one out for myself. Lucky for me, Steve [Bryen] has done this already and posted the workaround on his blog: