Cisco Collab and Open VMware Tools

Hi! I’m back with a quick take on Cisco Collaboration UCOS 12.5 and switching to open VMware Tools.

There is a long and bumpy history with native VMware tools on Cisco UCOS collaboration applications.  If you have had your UC solution for many years, then it is likely you have bumped into issues along with the way.  Keeping the native VMware Tools upgraded, installed, and working can be a challenge during upgrades.  So I was very excited in 12.5 you now have the option to move straight to Open VMware Tools.

What are these Open VMware Tools? In short – the better VMware Tools.  The open-vm-tools package is 100% supported by both Cisco and VMware. Moving to open-vm-tools will not take you out of any ‘compliance’ or get you yelled at by TAC.

The first advantage is that you’re de-coupling the ESXi version of tools from the UCOS application.  This means you’ll no longer need the “Check and upgrade VMware Tools before each power on” setting on the guest machine.  The open-vm-tools package is built into CentOS6/7 (and many others) by default, so you’ll no longer rely on the ESXi side of the house to get this right.  For example, if the systems team upgrades ESXi underneath your collaboration application you won’t have the additional worry of VMware Tools staying in sync.

For Cisco this means they simply keep the open-vm-tools package in CentOS6/7 UCOS and can keep it in line during application maintenance. I think it’s a win-win for both sides.

So how do we get there? EASY – but you do require a REBOOT. WARNING! You need to ensure that the native VMware Tools are operational prior to switching to open-vm-tools.  You can check the status of VMware Tools from ESXi. If there is a warning about version or operating system selection you need to fix that first. Also, please be sure you’re working with the latest patched version of the UCOS software release if you’re doing VMware Tools maintenance. There are some bugs and field notices that may get you stuck. Patch stuff!

This is primarily geared for 12.5 so as of this post I’m assuming you’re working with 12.5 SU2. VMware will give you the installed and running status for the tools.

Check that you have native VMware Tools operational

admin:utils vmtools status

Type: native VMware Tools

Now prior to making the switch and the reboot make sure you or someone else has UN-checked VM Options “Check and upgrade VMware Tools during each power on”.

Move the system to permissive.  This will relax Linux with a setenforce command.  This isn’t called out as required in all locations, but I’d certainly put it in the “recommended” category when making this switch.  You’ll easily be able to move the system back to enforcing.

admin:utils os secure status
OS Security status: enabled
Current mode: enforcingadmin:utils os secure permissive
OS security mode changed to Permissive

Make the switch to open-vm-tools package which will remove the native.

admin:utils vmtools switch open

This will uninstall the native VMware Tools and install the open-vm-tools.
The system will be rebooted automatically.
Do you want to proceed (yes/no) ? yes

The UCOS server will reboot and switch out the native for the open-vm-tools package. VMware will now show both installed and status, but it will read “VMware Tools is not managed by vSphere”.  You can also check at the UCOS CLI again with

admin:utils vmtools status

Type: open-vm-tools

Don’t forget to change back to enforcing!

admin:utils os secure enforce

In conclusion I think this was a good move by Cisco to bring the VMware Tools swap exposed natively with a UCOS CLI.  Getting away from those native tools and just getting it managed within CentOS is great.

I believe this will remain ‘Optional’ for quite a while, but it’s possible this will become a required changed for CSR14.

For more information from VMware about Open-VM-Tools check out the repo

Hit me up @Warcop on Twitter – Thanks!


Extra VMware Tools troubleshooting.

Got root? (Recovery ISO | Atl+F2) Make sure you’re working in the active partition by checking timestamps on /mnt/part1 or /mnt/part2.

/usr/bin/ will remove the tools

If you’re in a situation where you don’t have VMware tools in the active partition, then copy them from the inactive side. It’s likely they’re still over there. Find ‘vmware-tools’ directories on the inactive side and copy them over so that you can run the /usr/bin scripts.

Did you get stuck on a reboot and the only thing on the console is “Probing EDD”. Welcome to Field Notice FN70379 where you’ll need to generate new initramfs with “/usr/bin/ -d”