VM doesn't auto-start with ESXi5

[HeJumps]

I'm still learning pfSense, so I apologize for the newbish question.

I installed pfSense 2.0.1 i386 on a VM last night and configured it pretty successfully.  It's working very well, and I'm really liking it so far.  My only hiccup is that even after installing open-vm-tools, I cannot get my pfSense VM to start automatically in ESXi as I start the host machine from a cold boot.  The result is that the host and my client both pull a 169 IP address; I then connect to the host with that 169 address and start pfSense.  It works, but it adds a good 4-5 minutes to each boot, and it's kind of annoying.  :-\

Here's the dirty details:

• ESXI 5.0.0 update 1 (build 62868)

• pfSense 2.0.1-RELEASE (i386)

• Open-VM-Tools (8.7.0.3046 (build-313025) ) and Open-VM-Tools-8.8.1 (528969) from package manager are both installed

• vSphere client reports VMware Tools as Running (3rd-party / Independent) but correctly identifies the IP address

• Both of the VM's NICs are set up as E1000's

• pfSense is currently the only VM on the host, and is set to automatic startup

The diagnostic command prompts (from the help page - http://doc.pfsense.org/index.php/Open_VM_Tools_package) return this:

ps ax|grep vmware

$ ps ax|grep vmware
22360  ??  S      0:10.37 /usr/local/bin/vmtoolsd -c /usr/local/share/vmware-to
45135  ??  S      0:00.00 sh -c ps ax|grep vmware
45232  ??  S      0:00.00 grep vmware

kldstat

$ kldstat
Id Refs Address    Size     Name
 1   10 0xc0400000 1178ad8  kernel
 2    1 0xc1579000 6e00     vmblock.ko
 4    1 0xc158d000 5718     vmxnet.ko
 5    1 0xc342b000 4000     vmmemctl.ko
 6    1 0xc3696000 b000     vmhgfs.ko

Hope that's enough information.  I was thinking about trying the 64-bit version of pfSense instead, but the help pages mentioned that the 32-bit seems to be more stable.  I've done some searching already, but no one else seems to have this specific problem.

Thanks in advance for the help!  :)

[johnpoz]

The issue has nothing to do with tools - esxi 5 u1 has autostart broken.

Easy enough to correct with as script though.

Here
http://blogs.vmware.com/vsphere/2012/03/free-esxi-hypervisor-auto-start-breaks-with-50-update-1.html

In the comments you will find instructions for creating a script that autostarts the vms you want.

• First off, connect to your VMware ESXi hypervisor with VMware vSphere Client.
• Go to the Configuration-tab on the host
• Select Security Profile
• Preferences on services.
• Find SSH in the list and click Options
• Enable SSH
• Use a SSH-client like PuTTy to connect to your host.
• Once logged into the host, run the command "vim-cmd vmsvc/getallvms" to find all VMs on your host and theire IDs (first column). Note the IDs for the VMs you would like to autostart. Or if you would like to start everyone, theres no need to remember the ID.
• Now edit /etc/rc.local with the editor "vi" using this command "vi /etc/rc.local"
• To enter insert-mode in "vi" press "i"-key.
• Somewhere in that file (I put mine above the if-statement) write this if you want every VM to autostart:
• • for i in $(vim-cmd vmsvc/getallvms|cut -f1 -d" "|grep -v Vmid); do vim-cmd vmsvc/power.on $i; sleep 10; done
• And if you only would like to start a few of the VMs on the host, this will be enough:
• • vim-cmd vmsvc/power.on ID_OF_VM
• • sleep NUMBER_OF_SECONDS (10 in my case)
• • vim-cmd vmsvc/power.on ID_OF_VM2
• • etc…
• When you are done editing, press ESC-key to exit "insert"-mode and then write ":wq" to write and quit.
• Reboot your host and the VMs should autostart once again.

So for example - here is my script

The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.
~ # cat /etc/rc.local
#!/bin/sh

export PATH=/sbin:/bin

log() {
   echo "${1}"
   /bin/busybox logger init "${1}"
}

# execute all service retgistered in ${rcdir} ($1 or /etc/rc.local.d)
vim-cmd vmsvc/power.on 5
sleep 60
vim-cmd vmsvc/power.on 3
sleep 60
vim-cmd vmsvc/power.on 8

if [ -d "${1:-/etc/rc.local.d}" ] ; then
   for filename in $(find "${1:-/etc/rc.local.d}" | /bin/busybox sort) ; do
      if [ -f "${filename}" ] && [ -x "${filename}" ]; then
         log "running ${filename}"
         "${filename}"
      fi
   done
fi

~ #

That first one in the list is my pfsense vm, which yes runs my dhcp for my local network and my other vms that are not static.  So it needs to start first.  Then I start my linux box (got to have my shell) and then my storage/nas vm.  Other vms are just play things and don't have to be started upon a loss of power/restart or restart of my host, etc.

[Sailorsknot]

Are you sure the machine is configured to start automatically with the system?

vSphere Client - Select Server - Configuration Tab - Virtual Machine Startup/Shutdown - Properties - check "Allow virtual machines to start and stop automatically with the system" - Verify the Startup Order.

Hope this helps!

[johnpoz]

Its broke in U1, which he is running.

You have 2 options that I am aware of to get around it, roll back to pre U1 or use a script as I posted.

[Supermule]

Vsphere 5 is a major setback from VmWare…..

Glad I am still on 4.1 :)

[HeJumps]

johnpoz, that was the problem.  I added those lines to /etc/rc.local and it starts immediately now.  Thank you very much!  :)

[johnpoz]

Glad I could be of help - I was a bit confused as well when I noticed my autostart wasn't working upon my update to U1.  But since it worked before U1, I had a easier time tracking down the problem vs thinking it was something with the tools.

I keep an eye out for the next update what will fix it, but for now this works just as well - just not a gui to adjust it, etc.

[AshleyRBlack]

@Supermule:

Vsphere 5 is a major setback from VmWare…..

Glad I am still on 4.1 :)

In some respects.. yes.
But I love that fact i can now assign USB devices to VM's in 5.

[Supermule]

You can do that in 4.1 as well :)

The only problem is that if you run HA/DRS then the USB doesnt follow the VM. So if it moves of the server, then the USB is lost….

I dont know if they fixed that issue in V.5

[matguy]

@Supermule:

You can do that in 4.1 as well :)

The only problem is that if you run HA/DRS then the USB doesnt follow the VM. So if it moves of the server, then the USB is lost….

I dont know if they fixed that issue in V.5

First, HA and DRS are -very- different, not sure they should be lumped together like this.

As far as HA goes, I don't think you -should- expect any software to carry a hardware connection to a device through a hardware failure like that.  In an HA event the Host itself died (or rebooted) so the hardware host to your USB device is no longer functioning.

In 4.1 USB connectivity can be retained through a vMotion as long as the original host maintains connectivity and power and the VM Guests themselves remain powered on and not suspended.

A DRS event shouldn't break the connection, similar to a vMotion.  I have not directly tested this, if you're seeing otherwise, that may be a good reason to call VMWare support to possibly troubleshoot something that could be a bigger problem.  Otherwise, your DRS events should be triggered by performance issues, which I would presume other VMs should/would be moved first.  If you have a bunch of USB connected VMs on one host that seem to be heavy, manually vMotion them to balance the load, if needed.

Unless you're using Distributed Power Management and it shuts off a host that your USB devices are connected to, then obviously, that'll break it.

Basically, I don't think the loss of USB connection through an HA event complaint is all that valid.  You should not be -depending- on a directly attached USB device like that.  HA is all about recovering from hardware failures, and if you're depending on certain hardware, you're breaking that hardware ambiguity.  I know there's certain software that can require a USB "dongle" or key, but there are other USB over IP solutions that might work better in that situation.  (For the most part, that's pretty much what ESXi is emulating, anyway.)