The plugin will let you search for usernames in the vSphere Web Client search field and shows you the desktop(s) for this user.

If you log on to your Horizon View 5.2 Connection Server, and go to your connection servers installation directory, you will find the bits you need to start using this Plug-in.

In my case this is in

C:\Program Files\VMware\VMware View\Server\TechPreview\ViewAdminPlugin

This directory contains 3 files:
The README has al the information you need to make this work.

If you follow these steps, and log in to the vSphere Web Client with View Administrator Credentials, you can now search for a View user:

When you click on the View user, you get the Desktop VM’s for this user:

Pretty cool, isn’t it? Especially when you have moer than one entitled desktop for a user, or lot’s of users.

I would love to see more of these integration plugins so the vSphere Web Client will be a single interface for most day to day jobs.

Do keep in mind this is a Tech Preview so you might not want to install this on a production View Environment, but that is completely up to you off course.

I had a small issue with the Plug-in when deinstalling my View 5.2 RC version and Installing the GA version without unregistering the Plug-in first. The plug in would not work after I registered it from the GA version of the Connection Server

I will create a separate article discussing this issue and the steps needed to fix this jn the near future.

Eric Sloof from NTPRO.NL and myself proposed a session for this years VMworlds. We both do like the VMware vCenter Operations Manager product a lot, but see lots of people do not get the maximum out of it since they just use the standard dashboards that come with the product.
In our session we want to give you some real life examples from the field on how you can customize vCenter Operations Manager Advanced and Enterprise to show you the information you need. We will show you you don’t need to be a rocket scientist to make this happen.

We need your help to make this happen, so please vote for our session 5008 here

To make this session even more special, please reach out to Eric or myself if there is anything you really would like to see in a custom dashboard or metric, so we can try to accomodate this in our session.

We do need your votes. As independent contributors it gets harder and harder each year to compete with all the commercial and sponsor sessions on VMworld.

We would love to bring back some of the fun to VMworld, so vote for us, and we promise we will not let you down!

You will need to have or create a VMworld account to be able to cast your vote.

This session will teach you how to customize vCenter Operations to provide you the information you really need for your business.

You will get an insight of very useful vCenter Operations Manager customizations.

We do this by giving you some real life examples from the field where we use Custom Dashboards, Super Metrics, Adapters and Alerts in order to give you the best possible view in to the well-being of your environment.

This training course focuses on the advanced capabilities of VMware® vCenter™ Operations Manager™ 5.6, such as adapters, customization and management topics. You will learn how to use adapters, define custom super metrics, customize dashboards, and use the Custom user interface.

I have been fortunate enough to participate in an alpha training for this class and must say I enjoyed it very much. Very useful for people that want to customize their vCOps environment to show specific metrics or combined metrics

Cost for this training is around 50% of the normal price

See the attached info sheet, and if interested, register for this training here

Space is limited

beta announcement – vcops advanced 5 x

Those Dell systems had 4 Broadcom nics (2 x 1Gb + 2 x 10Gb) and 2 Intel 10Gb nics

Install went fine, and I decided to upgrade to the latest patches using esxcli since the hosts had no access to vCenter. All went fine till after the reboot. I noticed all Broadcom nics where missing from my hosts, most likely due to a driver issue, so time to investigate.

Here is what a host looks like before I installed the update vib ESXi510-201212001.zip 

As you can see the hosts has 6 nics, four using the Broadcom bnx2x driver and two using the Intel ixgbe driver.

After the upgrade the host looks like this:

So my Broadcom nics where gone …

Lets have a look at the drivers before and after the upgrade. Before the upgrade, the Broadcom OEM drivers version 1.74.17.v50.1-1 where installed, which are part of the Dell iso:

After the upgrade, the driver version was 1.16.15.v50.3-1, and these where VMware drivers:

So apparently the “upgrade” downgrades the Broadcom bnx2x drivers from 1.74.17.v50.1-1 to 1.16.15.v50.3-1, and the 1.16.15.v50.3-1 did not work on the nics in the R620 …

Looking at the output of the vib install on an other host confirms this behavior:

As you can see, the 1.16.15.v50.3-1 drivers are installed and the 1.74.17.v50.1-1 drivers are removed.

Sow how to fix?

The good thing is I always try to use nics of different vendors in my hosts, to prevent catastrophic issues with drivers like these. So my hosts still had access to my iSCSI array trough one of the intel 10Gb nics, and I could access the console via the Dell iDRAC.

Looking at the vSphere Download page I found an Offline Bundle for the Broadcom drivers: BCM-NetXtremeII-5.0-offline_bundle-940344.zip

I was able to put in on a VMFS volume using the Datastore Browser on a host I had not upgraded yet, and install it trough the iDRAC on the broken hosts:

After a reboot my host was back online and connectivity was restored.

So what did I learn?

• Do not trust the ESXi update procedure blindly. I did lots of upgrades in the past, but the process is not flawless and might install older non functioning drivers. If you relay want to be sure, use the vSphere ESXi Image Builder CLI to compare driver versions between the ISO and the update
• Test the upgrade on a single host (which I usually do, but since this was a new build, I did some hosts in parallel)
• Make sure you have access to the console or physical system when you do upgrades
• It does not hurt to have nics from different vendors in a host. I always try to do that in my designs, but this time it saved me a trip to the Datacenter …

Voting is open till the 1st of March

A special Thanks to Eric Siebert from vSphere-land for organizing this yearly event.

Debugging the VM performance issue with esxtop showed very high co-stop (%CTSP) vallues.

According to the vSphere Monitoring and Performance guide, %CTSP is

Percentage of time a resource pool spends in a ready, co-deschedule state.
NOTE You might see this statistic displayed, but it is intended for VMware use only.

The original vCenter server had a lot of custom roles and user permissions defind, on all kinds of objects in vCenter.

When we did the upgrade, we decided to install the SSO server on a separate server, and when we did the vCenter upgrade and it was registered with the SSO server, we suddenly received a message that users and groups where not found on the SSO server, which kind of made sense, since even though we recreated the users and groups on the SSO server, they had different security IDs. But what we did not expect, is the upgrade process decided to remove all non existing users and groups from the vCenter database, effectively removing all permissions from vCenter …

It would have been a lot more elegant if if would have kept the permissions and showed on an object the user or group object it refers to was gone, since now we had to reconfigure the complete permission structure. The custom roles did survive this upgrade.

So there are a couple of take aways from this:

• Start using AD when using SSO
• When using only local accounts and permissions in vCenter, install the SSO server on the vCenter server
• When not using AD and plan to install SSO on a separate server, document your complete permission structure.

I tried several things, like power off hosts, deregister initiators, power on host, reregister boot initiators and add registered host to storage group again, and reboot host, with and without restarting the VNX management servers,  before I found a solution that did work, which is kind of dirty if you ask me.

The solution is to put the ESX host in maintenance mode, enter engineering mode on the VNX, and deregister all logged in initiators for that host. Next, do a rescan on the host (which will not work because the deregistration removed the host from the Storage Group) to let the host register at the VNX, and add the newly registerred host to the correct Storage Group on the VNX again. Do an other rescan on the ESX host now to see your Datastores again.

IMPORTANT: Reboot your host after you did this, since a rescan of the Datastores does not Rescan your boot disk if you use Boot from SAN

Please remember this is could be a tricky operation since even though the host is in maintenance mode, you still yank the mounted LUNs from the host while it is running, which could cause an APD condition for instance, and the ESX host can probably only survive without its boot LUN for a limited amount of time. Unmounting the Datastores on the host in ESX 5 before deregistering could be a cleaner alternative, but have not tested that.

I received an error message “Error 29107. The service or solution user is already registered. Check Vm_ssoreg.log in system temporary folder for details”

I checked this log, but it did not really point me in to the right direction.

Then I found a post in the 5.1 beta archive that said the unique identifier for a service to register with SSO is the Common Name from its certificate.

Since I installed a wildcard certificate for both the vCenter Server and the Inventory Service, I thought this could be an issue, since both services have the same Common Name in that case.

I restored a backup of my vCenter Server, and then replaced my wildcard certificate by the default VMware certificates that where installed during the installation of my original vCenter Server, and retried upgrade. This time my upgrade finished successfully.

Since a commercial wildcard certificate always has the same Common Name, I do think that since the introduction of SSO in 5.1 and the way it uses the Common Name to distinguish between services, wildcard certificates can no longer be used for vCenter and its services unfortunately.

I hope someone can prove me wrong …

Update:

There is a KB article regarding this issue that can be found here

On several occasions we where not able to make config changes to some of our VSE devices when we tried to publish the changes we made from within vShield Manager. Whenever we tried to publish the changes, we received an error message in vShield Manager it could not reach the vShield Edge device we where trying to configure.

Next to that, we noticed a lot off errors in the vShield Manager System Events tab for this specific Edge Device regarding “Multiple heartbeats missed from appliance”

An other thing we noticed was the VMware Tools for this specific VSE device did not seem to be running.

We decided to open a case at VMware and where told this is a know issue with the version of vShield we are running (5.0.1) and this will be fixed in a future version. (It is not fixed in version 5.0.2 that was released recently)

The problems we see are caused by the fact the VSE device only uses a single filesystem, and this can cause the root filesystem to fill up when /var/log fills up. When that happens, you will see the issues as described above.

In the next version of vShield this will be addressed by using a seperate filesystem for /var (or /var/log) so when your log dir filles up, your root filesystem will not.

To confirm this is causing your issues, log in to the faulty VSE device via the console as admin user, and issue the command “show system storage”

As you can see in the example above, the root filesystem is full, which causes the issues as described above.

There are a couple of ways to fix this.

The official way is to open a case at VMware, and refer to their internal KB article 2032017 which describes this issue and what VMware needs to do to solve this. They can log in to the VSE device that has this problem to truncate the messages files in /var/log.
This solution is without any downtime.

If you need/want to fix this yourself, and you can afford downtime on the VSE device, you could power it off, mount its disk in a Linux VM, truncate the log files on the mounted disk, remove the disk from the Linux VM, and power on the VSE device again.

An other option that could work is to simply remove the faulty VSE device with the vSphere client. Whenever the vShield Manager syncs again with vCener, it will notice the missing VSE device and recreate it. This will also cause downtime. I was told by VMware this would be a solution that could work without involving VMware, but I have not confirmed this myself.