Yellow Bricks

by Duncan Epping

Bugs

Performance stats gone

· ·

Clint discovered the following:

Source –
Ran into a problem while doing some performance testing on some test VMs. We found that we had no historical performance data for the VM or Host. All we had was real time data. This can be a major issue, especially when you are trying to troubleshoot or like in this case get performance data for a performance test! My co-worker did some research and found that we are not an isolated event. This is a bug in VC 2.5.

The Fix

We found a few references to doing a “repair” install of VC 2.5. So we went ahead and tried it and it worked. We also found references to the performance data getting corrupted. In that case they had to restore the database to a prior dataset and re-install the VC.

I’ve seen the same at several customer sites and indeed the fix that Clint describes, repair of VirtualCenter, works.

Customization specifications fails during entering password

· ·

For some weird reason the customization specification wizard in VirtualCenter 2.5 fails when entering the administrator password. The error: An internal error occurred, and the wizard is unable to store the administrator password securely.

After reinstalling VirtualCenter the error still occurs. I googled the error and stumbled upon this VMware KB but this did not solve my problem…. I’m lost, anyone?

Fixed: Intel quad-port nic and VST

· ·

For those who encountered the same weird networking problems as I did, I was just browsing through the Knowledge Base articles for the patches released yesterday and found out that they fixed the driver for the Intel quad-port nic. When using VST half of the packets were dropped, for more info on the problem check these blogs: 1 , 2.

Fixed ESX Server support for Intel Zoar NICs on a VLAN trunking configuration. A flaw existed between the ESX Server networking subsystem and the igb driver.

Update Manager or documentation glitch

· ·

I was just testing the new patches on a couple of servers when I noticed that when I pressed “remediate” the first patch(ESX350-200802403-BG) was installed without the ESX host going into maintenance mode. When the second patch(ESX350-200802409-BG) was installed the server went into maintenance mode. According to the VUM Documentation(vi3_vum_10_admin_guide.pdf) the server should always go into maintenance mode before installing the patches:

Update Manager puts ESX Server in maintenance mode before applying updates. Virtual machines cannot continue to run when an ESX Server is in maintenance mode. To ensure a consistent user experience, Update Manager migrates virtual machines to other ESX Server hosts before the server being remediated is put in maintenance mode.

I can imagine this happens because the system impact of the first patch is “No VM Shutdown & No Host Reboot” and for the second patch it is “VM Shutdown & Host Reboot”. Anyway, it would be a nice addition if one could choose to always enter maintenance mode before applying patches. It definitely gives me a more save feeling.