Packer: [vmware-iso] Packer hangs while "Starting virtual machine..."

Created on 28 Mar 2014  路  13Comments  路  Source: hashicorp/packer

I've been using packer to build vagrant baseboxes for virtualbox, without any issues.

I now want to also build vagrant baseboxes for vmware workstation, but I run into some weird issues there.

Basically, I'm using the https://github.com/mitchellh/packer-ubuntu-12.04-docker repo for testing. If I start the packer build through packer build template.json, I see the following output:

==> vmware-iso: Creating virtual machine disk
==> vmware-iso: Building and writing VMX file
==> vmware-iso: Starting HTTP server on port 8555
==> vmware-iso: Starting virtual machine...

And that's it. Nothing happens afterwards, it's just hanging at this step.

I'm running on Windows 7, and I tried to build a vmware boxes with both packer 0.5.2 and 0.4.1, and VMWare Workstation 9.0.3 and 10.0.1 (and any combination thereof).

Any Idea what's going on?

Most helpful comment

@zettabyte

The only way I found that was by creating a new Ubuntu machine in VMWare Fusion, and digging through the vmx file. If you bust open a terminal and run the below command (obviously using a real path to the vmx file), you will get the output.

cat /path/to/virtual_disk.vmdk/virtual_disk.vmx | grep -i guestos

For Ubuntu 12.04 LTS 64-bit the above spits out:

guestOS = "ubuntu-64"

I just guessed on the capitalized 'u' in Ubuntu-64 as well. :)

Other than making a new image from scratch, and catting the vmx file, I'm not really certain where to find that piece of information. I've also failed to surface it with Google.

I feel like this was a recent change however...I have used Packer plenty of times to build Ubuntu disks, and only ran into this problem recently. My suspicion is that it's a VMWare issue, however, caused by a recent Fusion update...doesn't make sense for Packer to be the problem, since it's just building templates and letting VMWare build the disks.

I hope this helps.

All 13 comments

Also, I see the VM booting up correctly inside VMWare Workstation but the boot_command is never executed.

So, I tracked this down to some weird issue with the vmrun command - it never returns correctly. No idea what is going on - and googling around I didn't find anything that would help either. :disappointed:

Hey Arthur,
I don't know if this might be the issue, but I was having this problem this morning with ubuntu 12.04. I ended up tailing the vmware log and noticed that it said "Ubuntu_64" is not a supported OS.

I changed the value for "guest_os_type" to "Ubuntu-64" and it started right up.

Maybe check that and see if it helps? Don't know if it's a change in recent versions of Workstation/Fusion. I'm running Fusion on a Mac, so it's possible it's something else altogether.

@keithhamilton - where do you find documentation on valid values for VMware for the guest_os_type? I had this same problem the other day and changing the value from "Ubuntu 64-bit" to the valid value of "Ubuntu-64" worked for me (so, thanks for putting that recommendation here).

However, my Google-fu failed and I cannot find anywhere that lists all the valid, VMware recognized values for the guest_os_type. I'd like to know in case I need to determine the correct value to use for any other OS I attempt to build with Packer.

All I have as a reference is the VMware Fusion GUI (the general settings dialog) which has a tree-like selection bot for specifying the "OS" type. However, those values are clearly the "display" equivalents as the value for "Ubuntu-64" displays as "Ubuntu 64-bit" (which, of course, doesn't work in guest_os_type).

Any info is appreciated.

I upgraded to Windows 8.1, and that "fixed" my issue. Obviously, reinstalling the OS is not really a valid fix, but it helped me. I did not change anything else to get it to work.

@zettabyte

The only way I found that was by creating a new Ubuntu machine in VMWare Fusion, and digging through the vmx file. If you bust open a terminal and run the below command (obviously using a real path to the vmx file), you will get the output.

cat /path/to/virtual_disk.vmdk/virtual_disk.vmx | grep -i guestos

For Ubuntu 12.04 LTS 64-bit the above spits out:

guestOS = "ubuntu-64"

I just guessed on the capitalized 'u' in Ubuntu-64 as well. :)

Other than making a new image from scratch, and catting the vmx file, I'm not really certain where to find that piece of information. I've also failed to surface it with Google.

I feel like this was a recent change however...I have used Packer plenty of times to build Ubuntu disks, and only ran into this problem recently. My suspicion is that it's a VMWare issue, however, caused by a recent Fusion update...doesn't make sense for Packer to be the problem, since it's just building templates and letting VMWare build the disks.

I hope this helps.

@keithhamilton - Thanks for the response! Yeah, it's too bad there's no official reference, but your technique should be sufficient.

I've seen this sometimes, but it seems to be a strange issue with VMware I haven't been able to figure out yet. If we can figure out if Packer can work around this, please let me know and I'll happily do so. Otherwise, this unfortunately isn't a Packer issue.

I ran into this same problem. I used "headless" : "true" and it worked.
Also, on a side note, I had to remove cd drive in order for the machine to be created. Otherwise, packer kept search for "auto detect" file.

Here's a site with a very nice list of the vmx guest os options for VMware. http://sanbarrow.com/vmx/vmx-guestos.html

I also ran into this problem when creating windows 2012 R2 images with vmware

My solution was to change guest_os_type to windows8srv-64

  "guest_os_type": "windows8srv-64",

Once the guest_os_type is correct, vmware will start properly.

This is an old thread, but I think it's worth leaving this behind for the next person who runs into this. If you're running packer on a corporate machine, you may have a security suite installed that interferes with vmrun and prevents it from returning.

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2050353

In my case, I had to temporarily disable the firewall and host IPS on my laptop. Once that's done, McAfee allows the procedure to finish. For me, this wasn't a Packer issue, it was a security software issue.

I've just run into this and took quite a bit of digging in the hostd.log to work out what it was. So, adding for maybe more searchability:

2017-04-19T19:15:36.254Z error hostd[41744B70] [Originator@6876 sub=Default opID=a8bde297 user=root] Unable to convert Vigor value 'Windows2012_64' of type 'char const*' to VIM type 'Vim::Vm::GuestOsDescriptor::GuestOsIdentifier'

In my case I had moved from a virtualbox template to a vmware one, and didn't really pay attention to this os type value. But the behaviour of just repeatedly trying to start without any error message more specific than "general error" wasn't very enlightening.

Was this page helpful?
0 / 5 - 0 ratings