Today I installed a demo of Horizon View 6.2 using linux Desktops: it works, but it is not yet very straight-forward, it lacks some major features, for example:
- single sign-on
- automated pools, linked clones etc...
I will make more experiments in the next days and see how far I can get, waiting for Horizon 7 ga.

Ubuntu linux accessed throught View Horizon

Hosts don't reconnect after VUM upgrade to build 3248547

Recently VMware disabled SSLv3 protocol in vCenter/ESXi 5.5u3b.

A sideffect of this is that, as noted in the interoperability matrix, vCenter 5.5u3b is needed to manage ESXi 5.5u3b hosts.

Trouble is: if you use VUM to update your hosts you usually end up in a situation where vCenter is upgraded much less often than the ESXi, and you may still be running vCenter < 5.5u3b when VUM pushes to you the patches that will bring ESXi to 5.5u3b.

If you upgrade the hosts with VUM, after the reboot:
- vCenter will not be able to reconnect them
- you will receive "vim.fault.NoHost" errors when trying to reconnect them manually
- you will be able to connect normally to the host by vSphere client
- you will find SSL errors in the vpxd.log log of vCenter, basically in the form of "SSL short read" faults.



Explanation:

The reason behind the error is given in the release notes:

The release notes point to the KB 2139396 that describes the steps needed to *REENABLE* the disabled protocols: this is obviously discuraged, but is an effective workaround to put the hosts back online in vCenter until the vCenter itself can be upgraded to 5.5u3b.


Workaround: *USE AT YOUR OWN RISK*

To "fix" the hosts you have to follow the steps in the KB that relates to the ESXi - *NOT* those that refer to the vCenter

Kb:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2139396

So (follow the more precise indications in the kb):
- enable SSH by the vSphere client on the disconnected hosts
- connect to the hosts with putty/ssh as root
- Follow the steps in the chapter "Hostd - Port 443" of the KB (edit config.xml and add the indicated options)
- Ignore the "HostProfile" part since it matters only if you use autodeploy or host templates
- Follow the steps in the chapter "Authd - Port 902" of the KB (esxcli with the indicated options, restart the watchdog)
- Ignore the "HostProfile" part since it matters only if you use autodeploy or host templates
- Follow the steps in the chapter "SFCBD - Port 5989" of the KB (edit sfcb.cfg and add the indicated options, restart the watchdog)
- Ignore the "HostProfile" part since it matters only if you use autodeploy or host templates

If vSAN is in use the chapters "Virtual SAN VP - Port 8080" and "Virtual SAN Observer - Port 8010" should also be followed, but I don't advice messing up with this configs on a vSAN enabled cluster!!!

*IN TEORY* this works fine, but I don't advice this workaround in production and in a supported environment, since your system will be *OUT OF THE INTEROPERABILITY MATRIX* and since you will re-expose your system to the poodle security vulnerability.

The best option is probably to leave the upgraded ESXi disconnected and upgrade vCenter to 5.5u3b.

looking up MAC addresses of ESX NICs in a network switch

I'm struggling to identify to wich ports on a Ge switch a new ESX host has been connected.
First, I checked esx.conf to identify each virtualMac for each nic, then I asked the network gurus to check them out with fdb. Weirdly, not all the MAC's are in the forwarding db. My next try is to put all the nics as uplinks in a vSwitch, and enable nic teaming with beacon probing: I think the beacons broadcasts will update the fdb for each MAC in the switch: will it work?!? Beacon probing is explained in this article.

how to check wich db is a vCenter using

To know wich ODBC sources is being used by a vCenter and Update Manager, one needs to check the registry of the windows machine.
After you know the ODBC source, you can open it and see wich db and witch server it is pointing to.

HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter\DB

the same for the update manager. 


source: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003928

error printing from vmware to cups

On my linux machine I use vmware workstation 7.0.1 to run several windows machines. In each I use virtual printing to let the printers I configured on my host machine appear as local printers, without the need to share them throught samba or to configure them on each single vm.

From time to time (after upgrades) my virtual printer ceases to work: when I print from the vm the job fails and in my host machine I get an error from cups "stopping job because the scheduler could not execute a filter"

This seems to be caused by the filter

/usr/lib/cups/filter/thnucups

wich is incorrectly set to permissions "-rwsr-xr-x" instead of 555 "-r-xr-xr-x" as all the others.

to fix the problem, just set the permissions to 555

sudo chmod 555 /usr/lib/cups/filter/thnucups