Posted by

vminstructor

Posted on

October 28, 2014

Posted under

Networking, Troubleshooting, Updates, vCenter, vSphere

Comments

Leave a comment

VMware KB: Unable to open a virtual machine console using the vSphere Web client in VMware vCenter Server 5.5 update 2

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

Posted by

vminstructor

Posted on

October 9, 2012

Posted under

Troubleshooting, vCenter, vSphere

Comments

Leave a comment

Clearing up an AD Lightweight Directory Service error on vCenter Server systems

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).
http://blogs.technet.com/b/askds/archive/2010/04/09/friday-mail-sack-while-the-ned-s-away-edition.aspx#adws

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.

Posted by

vminstructor

Posted on

September 26, 2012

Posted under

Networking, Troubleshooting, Uncategorized

Comments

Leave a comment

Working with Linux based virtual appliances

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.
/etc/udev/rules.d/70-persistent-net.rules
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!

Posted by

vminstructor

Posted on

November 9, 2009

Posted under

Troubleshooting, View, VMware

Comments

Leave a comment

VMware View 4 Beta/POC

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!

Posted by

vminstructor

Posted on

November 7, 2009

Posted under

Troubleshooting, vCenter, VMware, vSphere

Comments

Leave a comment

Licensing VMware ESX 4, ESXi and vCenter 4 Video KB article

This week VMware posted KB article 1010839 on licensing ESX 4, ESXi 4 and vCenter 4. I get many questions in class about the new license assignment process for vSphere. This KB article has a nice video demonstration and very concise text direction for assigning licenses.

Posted by

vminstructor

Posted on

May 1, 2009

Posted under

Troubleshooting, VMware

Comments

Leave a comment

VMware KB Resolution Paths

Last week I saw a post on the VMware Knowledge Base Blog with resolution paths for Converter. This morning I noticed that resolution paths have been posted for most VMware products and problem areas. The Resolution paths are a matrix that walk you through recommended troubleshooting steps with hyperlinks to related KB articles for each step. Here is the link: http://blogs.vmware.com/kb/2009/05/resolution-paths-published.html

Posted by

vminstructor

Posted on

April 28, 2009

Posted under

Troubleshooting

Comments

Leave a comment

Troubleshooting…

Today at a client site, vCenter stopped responding. In the course of troubleshooting, I discovered that the C: drive of the SQL server housing the vCenter database had 1.59MB free. That was alleviated by cleaning up a 526MB system state backup from late 2007. Next, I found that the SQL DBA’s had set the SQL login for the vCenter db to expire. The VMware admins confirmed that they had requested a login with no account expiration and that the request had been approved through change control before the account was created. Of course, this is not the default setting, so care must be taken to confirm the config.

At the same site we also discovered that the VLAN tags for a single VLAN were left off of 22 physical ports… Simple typo in the console “1-2” rather than “1-24” that was showing up as intermittent inability for VM’s to get ip addresses via DHCP. Based on good documentation of the vSwitch configs and a good diagram and documentation of connections from the ESX hosts to the physical switch, we convinced the network admin to check and correct the switch config.

Thankfully, both errors were remedied quickly, but both could have been avoided with careful checking and better feedback. Virtualization crosses many disciplines and I routinely encounter resistance from the various admin groups at client sites who have become isolated from each other. At this site, the admin groups are starting to loosen up and cooperate better, and incidents like today’s are helping them to appreciate the need for coordination rather than insulation.