VMware KB: User Name and Password fields does not appear on the vRealize Automation login page.
This problem is between the vRealize Automation 6.2 Client integration plug-in and recent versions of Firefox.
As a workaround, you may be able to move the horizontal scroll bar, causing the screen to be redrawn, thus revealing the username and password input boxes.
Internet Explorer 11 appears to be pretty well behaved and the latest versions of Chrome also work well, though the Flash components may be old.
VMware KB: Registering NSX Manager to vCenter Server or configuring the SSO Lookup Service fails with the error: nested exception is java.net.UnknownHostException.
I have seen this error with customer installations. Even if you don’t run across the error, this KB contains very succinct instructions for troubleshooting basic infrastructure requirements for NSX Manager.
VMware KB: Creating an NSX logical switch fails with the error: Unable to allocate an available resource.
A couple of students mentioned this error during a lab in the VMware NSX: Install, Configure and Manage class this week.
The issue is simple to create and remedy. Logical switches are assigned VNI (VXLAN Number Identifier) from a Segment ID Pool. If the Segment ID Pool is not configured before you try to provision a logical switch then you will get the “Unable to allocate an available resource” error. The resolution is to configure the Segment ID Pool before attempting to create Logical Switches.
VMware KB: Unable to open a virtual machine console using the vSphere Web client in VMware vCenter Server 5.5 update 2.
This KB article restates an item from the vCenter 5.5 Update 2 release notes:
Virtual machines with HTML 5 console in vSphere 5.5 open connections with http:// instead of https://
When the HTML 5 console is launched on a virtual machine, it uses connections like http:// and web sockets like ws:// instead of secure connections like https:// and wss://.
This release resolves the issue by launching the virtual machine console with secure connection over port 7343 instead of the connection over port 7331.
This was a welcome change, but it introduces a potential connectivity issue for those who don’t read the release notes!
Here is a link to the release notes: https://www.vmware.com/support/vsphere5/doc/vsphere-vcenter-server-55u2-release-notes.html#networkingissues
Here is the top level KB article for required TCP and UDP ports for vSphere products. Notice the left hand column where the version numbers are listed!
TCP and UDP Ports required to access VMware vCenter Server, VMware ESXi and ESX hosts, and other network components
Recently I was onsite with a customer helping them deploy a new vSphere 5.1 environment to host a new Exchange 2010 system. As part of the deployment, we setup Alan Renouf’s vCheck 6 script and started working through the process of setting it up to run as a scheduled task. As we were manually running the task we noticed that the output showed errors every minute for the AD Web Services and AD Lightweight Directory Services (ADAM).
We found the log entries in the AD Web Services log.
A little digging uncovered that the event 1209 error is reported when there is a problem with the port numbers in the registry for AD Web Services LDAP access (389/636).
On inspection of the registry key, the “Port SSL” type is incorrect and the data is missing. According to the Technet blog post, the value type should be “REG_DWORD” and the default data is 636.
I deleted the existing incorrect value and created a new value with the REG_DWORD type and the value data of 636 decimal.
Upon checking the Windows event logs, I could see that the AD Web Services was already using the corrected value, so no service restart was required.
The next log entry displayed the VCMSDS instance and LDAP/LDAPS (SSL) ports it is configured to use.
After this vCenter system was fixed, we checked all of the other vCenter servers onsite and found that their vCenter 4.1 server they were using for non-production also had the same error. That vCenter server was running on a Windows 2003 server and we did have to stop and restart the AD Web Services service to load the corrected SSL port value and resolve the error.
Thanks to Alan Renouf and the vCheck contributors at Virtu-Al.net for grabbing and displaying this error.
Recently I have been getting ready for upgrades and deployments of vSphere 5.1/vCloud Suite 5.1 in my lab abd at client sites. I have used the ESX Deployment Appliance for several years and have had good luck with it. This time I ran into an issue that caused me to remove and reinstall the virtual nic on the EDA appliance. I noticed that the ifconfig output looked odd and remembered that I should make sure that /etc/udev/rules.d/70-persistent-net.rules doesn’t have any entries with “old” MAC addresses, particularly for “eth0.”
As I was troubleshooting the “network is unreachable” error, I did a search and found a reference to documentation I used to regularly provide to customers that were deploying Linux VM’s from templates…
Remove network configuration
The MAC address of the VM’s virtual nic is written into the udev persistent rules and needs to be cleaned out as the cloned vm will have a different MAC address.
Remove entries containing “eth0”
It had been a while since I wrote that and I am glad I still had it.
As soon as I cleaned out the old entries and restarted the VM, the networking came to life and I am now back to work!
Today, I had the good fortune to work with Todd Dayton, A VMware specialist on all things VDI/View related. The client I am working for had been accepted into the View 4 beta and Todd was onsite to help with the install and config of View and some thin clients.
We relearned a pretty common lesson in IT that a clean install is generally better than an upgrade. In an effort to save a few minutes, we decided to upgrade existing View 3 components. The connection server worked well, and the View composer worked, but the View 3 agent and the VMware tools from ESX 3.5 caused us to have problems with PCoIP connections. After removing the new agent, then removing the old VMware tools, we reinstalled the VMware tools for ESX 4 and finally the View 4 agent. After this remediation things worked like a charm!
If you haven’t tried PCoIP, you must! It blows the doors off RDP. I can’t wait to get the released bits and get this into production. Thanks Todd for the assistance!