Installing VMWare Tools on JunOS SPACE

[Edit 2016-04-27] Updated for JunOS SPACE 15.2r1.

JunOS SPACE, Juniper’s management platform for JunOS devices (switches, routers, firewalls) does not come with gcc or kernel-headers. Installing VMWare Tools from a mounted ISO via vmware-install.pl is not all that successful. Happily, VMWare still provides RPM versions of those tools. SPACE 15.2 is built on CentOS 5, which in turn is a RHEL 5 clone.

This post will be around when SPACE 15.2 is history. To check for version of the underlying OS, run:

rpm -qa | grep ‘base.*centos’

(thanks to Riley in the comments for that)

Be sure to use the VMWare Tools package that matches the version of CentOS your SPACE is running.

1) Start by downloading the RPMs for VMWare Tools on RHEL 5. You’ll want the following (or their current equivalent):

vmware-tools-core-10.0.6-1.el5.x86_64.rpm
vmware-tools-esx-nox-10.0.6-1.el5.x86_64.rpm
vmware-tools-foundation-10.0.6-1.el5.x86_64.rpm
vmware-tools-guestlib-10.0.6-1.el5.x86_64.rpm
vmware-tools-libraries-nox-10.0.6-1.el5.x86_64.rpm
vmware-tools-plugins-autoUpgrade-10.0.6-1.el5.x86_64.rpm
vmware-tools-plugins-deployPkg-10.0.6-1.el5.x86_64.rpm
vmware-tools-plugins-grabbitmqProxy-10.0.6-1.el5.x86_64.rpm
vmware-tools-plugins-guestInfo-10.0.6-1.el5.x86_64.rpm
vmware-tools-plugins-hgfsServer-10.0.6-1.el5.x86_64.rpm
vmware-tools-plugins-powerOps-10.0.6-1.el5.x86_64.rpm
vmware-tools-plugins-timeSync-10.0.6-1.el5.x86_64.rpm
vmware-tools-plugins-vix-10.0.6-1.el5.x86_64.rpm
vmware-tools-plugins-vmbackup-10.0.6-1.el5.x86_64.rpm
vmware-tools-services-10.0.6-1.el5.x86_64.rpm
vmware-tools-vgauth-10.0.6-1.el5.x86_64.rpm

That list might change with newer versions of the tools and of RHEL, of course. When in doubt, grab just the vmware-tools-esx-nox package, try to install it, and take a note of all the dependent packages it wants, then download those too.

2) scp the lot to SPACE, say to /var/tmp. While WinSCP is unhappy with the shell the admin user runs on, command-line scp does not care and will work. Choose any version you like: The one that comes with Putty, the one that comes with Cygwin, an Ubuntu one on Windows 10, or any other. And if you’re running OSX or Linux, you can feel extra-smug because you have scp as part of your base OS.

3) Install those RPMs. Now, you could install the GPG key they are signed with, but if you trust that you got them from VMWare, in an unaltered form, then just:

yum install --nogpgcheck vmware-tools*rpm

If there are dependency errors, download the missing packages as well and try again.

5) Satisfy yourself that vmtoolsd is running:

service vmware-tools-services status

 

vSphere should now be reporting that SPACE is running “VMtools 3rd party/independent”. And that’s all there is to it.

The kmod portion of the tools won’t install, by the way – but then it’s not needed.

 

Recover Juniper SRX from failed boot

I have a Juniper SRX240H in the lab. I decided to load a beta version of JunOS, which brought the unit into a state where it did not successfully boot, and where I could not use the loader> prompt to recover from TFTP.

The symptoms were:

  • During boot, the SRX would experience a fault and enter the db> prompt. I believe this to be a debugger, possible gdb. “c” will cause it to reboot again
  • If I enter the loader> , I cannot execute setenv – I get a “stack underflow” error. This means I cannot install JunOS from TFTP

I may have been able to recover this system using a USB key, but I am remote to my lab: All I have is serial console.

I resolved the issue by entering u-boot instead of the loader. u-boot prompts right after boot, and the loader prompt is shown shortly thereafter. The u-boot prompt is “Press SPACE to abort autoboot in 1 seconds”, and the loader prompt is “Hit [Enter] to boot immediately, or space bar for command prompt.”

In u-boot, I issued this command:

=> getenv

This showed me that boot.current=primary

I changed this to the alternate slice, which still held a working copy of JunOS:

=> setenv boot.current alternate
=> boot

The system came up successfully and warned me that I had booted from the alternate slice, and it rebuilt the primary slice:

***********************************************************************
**                                                                   **
**  WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE      **
**                                                                   **
**  It is possible that the primary copy of JUNOS failed to boot up  **
**  properly, and so this device has booted from the backup copy.    **
**                                                                   **
**  The primary copy will be recovered by auto-snapshot feature now. **
**                                                                   **
***********************************************************************

The auto-snapshot feature that was used here needs to be configured (set system auto-snapshot) and supported by the version of JunOS you’re running.

Lastly, I confirmed that the snapshot had been repaired, then rebooted:

root@SRX-Lab-2> show system snapshot media internal
Information for snapshot on       internal (/dev/da0s1a) (primary)
Creation date: Nov 13 12:53:04 2013
JUNOS version on snapshot:
  junos  : 12.1X44-D20.3-domestic
Information for snapshot on       internal (/dev/da0s2a) (backup)
Creation date: Oct 4 17:13:17 2013
JUNOS version on snapshot:
  junos  : 12.1X44-D20.3-domestic
root@SRX-Lab-2> request system reboot