Hello everyone,
While using the builder vmware-iso
with option "headless": true
packer aborts directly after starting the virtual machine:
~
Error starting VM: VMware error: Error: The operation was canceled
~
For more details please have a look at my gist. In short:
vmware-iso
Without this option, everything works as expected.
I've also tried tweaking the option version
based on a list of virtual hardware versions provided by VMware. There's no chance to start the machine in headless mode. Same on a Debian 9 x64.
Am I missing something? Thanks in advance.
Ben
what happens when you run /usr/bin/vmrun -T player start builds/mylittlehost-vmware/mylittlehost-vmware.vmx nogui
without using Packer?
Almost the same:
~
$ /usr/bin/vmrun -T player start mylittlehost-vmware.vmx nogui
Error: The operation was canceled
~
…while…
~
$ /usr/bin/vmrun -T player start mylittlehost-vmware.vmx
~
…is working. I've added the file vmware.log to the gist.
That makes it seem to me like this is a vmware bug unrelated to Packer; this OS may not work with vmware in headless mode.
Ok, seems valid. I've tried it with Ubuntu 18.10, 19.04 and Debian GNU/Linux 9.9. Can you recommend any OS which should work?
This may be a better question for the mailing list or community forum; I maintain Packer but I'm not an expert in every platform.
Running into this exact issue, anyone else affected by this?
# vmrun -T player start packer-vmware-iso.vmx nogui
Error: The operation was canceled
Unable to do away with the headless option:
# vmrun -T player start packer-vmware-iso.vmx
Error: Cannot launch the UI because no display server is present in the current environment
The error presents like this from Packer:
$ packer build template.json
vmware-iso output will be in this color.
Warnings for build 'vmware-iso':
* Your vmx data contains the following variable(s), which Packer normally sets when it generates its own default vmx template. This may cause your build to fail or behave unpredictably: numvcpus, memsize
==> vmware-iso: Retrieving ISO
==> vmware-iso: Trying iso/CentOS-7-x86_64-Minimal-1810.iso
==> vmware-iso: Trying iso/CentOS-7-x86_64-Minimal-1810.iso?checksum=sha256%3A38d5d51d9d100fd73df031ffd6bd8b1297ce24660dc8c13a3b8b4534a4bd291c
==> vmware-iso: iso/CentOS-7-x86_64-Minimal-1810.iso?checksum=sha256%3A38d5d51d9d100fd73df031ffd6bd8b1297ce24660dc8c13a3b8b4534a4bd291c => /home/centos/packer/centos2/packer_cache/4920629fbf7b8210982c72ae5f3a4e81759cf662.iso
==> vmware-iso: leaving retrieve loop for ISO
==> vmware-iso: Creating required virtual machine disks
==> vmware-iso: Building and writing VMX file
==> vmware-iso: Starting HTTP server on port 8546
==> vmware-iso: Starting virtual machine...
vmware-iso: The VM will be run headless, without a GUI. If you want to
vmware-iso: view the screen of the VM, connect via VNC with the password "[redacted]" to
vmware-iso: vnc://127.0.0.1:5985
==> vmware-iso: Error starting VM: VMware error: Error: The operation was canceled
==> vmware-iso: Waiting 4.77334343s to give VMware time to clean up...
==> vmware-iso: Deleting output directory...
Build 'vmware-iso' errored: Error starting VM: VMware error: Error: The operation was canceled
==> Some builds didn't complete successfully and had errors:
--> vmware-iso: Error starting VM: VMware error: Error: The operation was canceled
==> Builds finished but no artifacts were created.
Switching to Workstation Pro 15.1 on Ubuntu 19.04 solves the problem. Headless mode is working fine now but costs ~250 €. Not sure if it's worth it…
Ended up using a ESXi server we had sitting around for a remote host build, was able to get around the issue after that.
It'd be nice if a free VMware product would work here though.
I've run into similar issues in the past. Starting VMware in headless mode from Packer doesn't appear to initialise or start up VMware properly - hence the issue. The same is true when using the CLI vmrun
commands. This seems to be a bug in VMware.
To 'solve' the issue I had to start VMware once using the GUI. This would then initialise everything correctly after which I could then close the GUI and quit VMware. After this 'start up and shutdown via the GUI' Packer would run happily in headless mode.
It's a bit strange I know but it seemed to do the trick. I usually came across this problem straight after I had rebooted. Clearly, at this point I hadn't yet started VMware via the GUI at any point and so saw the issue...
I am using VMware Fusion Professional Version 8.5.10 (7527438).
Clearly, this issue may have been fixed with the newer versions of VMware Fusion/Workstation...
came across this in VMware Workstation 15.1.0 build-13591040 @DanHam your workaround does not apply to me
applies to me also on VirtualBox.
im building on a few hypervisors these days and VirtualBox gives me:
has terminated unexpectedly during startup because of signal 6
which is almost identical to this thing here
im using vmware-vmx
and virtualbox-ovf
@SwampDragons could you double check this 4 us if its not related to packer ?
The issue for me was related to the fact that VMWare does some magic when accepting the evaluation license from the GUI and seemingly nowhere else.
I could install VMWare workstation completely from the CLI using flags on the bundle file:
bash ./vmware-workstation-full-latest-blah.bundle --console --eulas-agreed --required
But my headless Packer builds would continue to error out when executing vmrun due to no valid license:
Packer log:
2020-04-03T13:47:03-07:00: Build 'vmware-iso' errored: Error starting VM: VMware error: Error: The operation was canceled
vmware.log:
2020-04-03T13:48:19.951-07:00| vmx| I125: [msg.License.no_valid_license_see_website] Cannot find a license key to unlock this version of vmrun.
2020-04-03T13:48:19.951-07:00| vmx| I125+ Go to our web site at "http://vmware.com/info?id=27&build=15785246" to obtain a valid license key.
2020-04-03T13:48:19.951-07:00| vmx| I125: ----------------------------------------
2020-04-03T13:48:19.951-07:00| vmx| I125: MsgIsAnswered: Using builtin default 'OK' as the answer for 'msg.License.no_valid_license_see_website'
2020-04-03T13:48:19.951-07:00| vmx| I125: LICENSE no valid one found
2020-04-03T13:48:19.951-07:00| vmx| I125: Module 'License' power on failed.
My solution was to monitor the process the VMWare GUI was calling when accepting the Eval License (HINT: auditctl -m and ausearch -i are your friend):
/usr/lib/vmware/bin/vmware-setup-helper -n "VMware Workstation" -v 15.0+ -s M56JK-GY3E1-489PA-0H900-A0H16 /usr/lib/vmware/licenses/site/license-ws-150-e1-201804 /etc/vmware/license-ws-150-e1-201804
Once I determined this, I executed it manually after a fresh install of vmware and everything worked. No GUI needed!
Note 1: VMware likes to be installed and run as root and not through sudo for some reason. This fixed other errors I was encountering prior to the license issue.
Note 2: If there is already a license file in /etc/vmware the command above will error out.
Thanks for that workaround -- I'm not sure it's Packer's place to autogenerate this eval license (the legality of us automatically doing that for users seems fuzzy at best here) so I'm not sure what we can do on Packer's side except maybe document that this could be an issue. Thoughts?
I agree that documentation would be the best option. Testing headless packer builds in a dev environment as close to production-ready as possible, I like the option of not having to worry about the license. In a production environment, I would absolutely apply for a valid license before pushing my code.
It seems that the serial number is generated on install of VMware so I am not sure if my previous command would work for other users. It could be random and doesn't really matter but I'd prefer it if someone else attempts my solution and responds back if it works.
/usr/lib/vmware/bin/vmware-setup-helper -n "VMware Workstation" -v 15.0+ -s M56JK-GY3E1-489PA-0H900-A0H16 /usr/lib/vmware/licenses/site/license-ws-150-e1-201804 /etc/vmware/license-ws-150-e1-201804
At some point, I will wipe out my test server and try it again from scratch to verify.
I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.