the Zen of Communication.

Setting up a new pool (persistent linked clone, in this instance) for VMWare View 4. Had the template built, took a snapshot, then tried to create the pool. Got all the way through setup to select the template and snapshot, but voila. Snapshot wasn’t there.

VMWare View templates require the snapshot to be taken WITHOUT the VM memory state. If the memory state is taken with the snap, the snapshot isn’t available – except it won’t tell you why.

VMWare also highly recommends/suggests that the VM template be powered off. This makes a lot of sense, and you really should, but I had two snaps taken with the system powered on which I built VDI Persistent Linked Pools from, and 10 desktops worked fine.

A client is using a mixed environment, with several VMWare ESXi clusters, and several ESX clusters.  They’ve been running a number of maintenance tasks through SSH on the ESX clusters, but believed one could not get to a console under ESXi 3.5.  I found a quick howto:  http://www.vm-help.com/esx/esx3i/ESXi_enable_SSH.php

The short of it is you have to enter a debug mode in the console.  From the main console window, press ALT+F1 to get to the console terminal.  You’ll start out with:

(names have been changed to protect the innocent).  And after hitting ALT+F1, you’ll get:

Whereupon you’ll type “unsupported” (no quotes) and hit enter, and it will not be visible.  Just trust me, it’s there.  You may need to try it a couple of times if the console has had any keypresses still in the buffer.  Afterwards, you’ll get:

Enter your root console password here.  You’ll get dumped to a linux prompt.  Know this: Yes, it’s “linux”, but it’s stripped.  Many rudimentary functions are not present. 

From here, edit /etc/inetd.conf (using vi).  Scroll down until you find the line with “#ssh” .  Remove the # to enable the line .  (the vm-help.com page has detailed vi instructions.  I won’t go into those here.  But here’s more help) 

Once you’ve uncommented the ssh service, write and quit.  Then run /sbin/services.sh restart. 

Now, every other howto out there would leave you believing you should be all set.  If you’re anything like me, you’ll reboot your host, and then wonder where you went wrong.  In life.  After all, 5 or 10 how-tos have the same instruction set, and everyone else said “hai this rox kthxbye!”.  And yet I followed the instructions and I still had no joy.  I killed the inetd process numerous times, and had no joy.  What was a frustrated sysadmin who enjoyed such problems as this to do?  Get cracking.

I eventually hit the logs and discovered a couple of parameters were missing for their implementation of the ssh server, dropbear.  The path in the /etc/inetd.conf file was simply /sbin/dropbear .  For kicks, I tried to run ./sbin/dropbear.  It, in a world of generosity, spit out a list of symlinks I needed to create.

If I’m remembering this right, I did what it asked but it still didn’t work.  So, the actual path I ended up using in /etc/initd.conf was:

/sbin/dropbearmulti [tab] dropbear ++min=0,swap,group=shell –i

This calls the dropbearmulti app, and instead of using the symlink method it’s asking for, just tells it “here, run the server, and here’s your arguments.” .  It seems to be working, because several weeks and a few reboots later I’m SSH’d into the server to pull up the details for this post.