Vagrant: `vmrun` error with VMware

[jack7890]

My company uses Vagrant within VMware for development. Everyone else (10+ people) has the setup running smoothly, but I've run into a confounding problem that none of us can solve.

After adding a vagrant box with vagrant box add sgvm http://files.vagrantup.com/precise64_vmware.box I try to start vagrant with vagrant up seatgeek --provider=vmware_fusion. This throws this error:

An error occurred while executing `vmrun`, a utility for controlling
VMware machines. The command and output are below:

Command: ["start", "/Users/jack/Sites/sg/seatgeek-vm/.vagrant/machines/seatgeek/vmware_fusion/f2e2bebf-e1cb-4bc1-862b-9cb957e13065/precise64.vmx", "nogui", {:notify=>[:stdout, :stderr]}]

Stdout: 2014-02-06T09:20:29.661| ServiceImpl_Opener: PID 20276
Error: The operation was canceled

Stderr:

I got in touch with VMware support. They said that they can't support Vagrant, but they would confirm that vmrun was working properly. They asked me to run vmrun -T fusion start and verified that the output was expected. Based on this, they said it was a Vagrant problem.

I'm running Vagrant 1.4.3 with VMware Fusion 6.0.2 on OS X 10.9.1.

I initially posted this on StackOverflow, and it was suggested that I create an issue here.

[mitchellh]

Jack,

Ah! I am very annoyed that VMware said it is my problem. The "The operation was canceled" error (fantastic in its vagueness), has _always_ been a VMware problem to date. It can mean a variety of things, I've found out, none of which Vagrant can really detect or do anything about, especially because the error is so vague:

• Virtualization extensions aren't enabled on the CPU
• Your trial has expired or the application requires a license key
• Permission problems on the install (corrupted install)
• You need to fill out some form data in the GUI.

The best way to determine what is going on is to enable the GUI from the Vagrantfile so Vagrant doesn't launch it headless. This _usually_ results in Fusion properly showing an error message.

[jack7890]

@mitchellh you're right! We eventually figured out that VMware was had a setting telling it (Lord knows why) to use all the cores on my machine. Once we killed that, the problem went away.

Sorry to bother you, and thanks for the advice.

[jgrevich]

I'm getting the same error. @mitchellh where did you find that setting? I tried specifying the number of cores in my vagrant file but that didn't help.

[jgrevich]

@mitchellh It sounds like you had a different issue. I searched though the log and found this:

2014-02-27T15:46:43.796-08:00| vmx| I120: Msg_Post: Error
2014-02-27T15:46:43.796-08:00| vmx| I120: [msg.cpuid.noLongmode2] This virtual machine is configured for 64-bit guest operating systems. However, 64-bit operation is not possible.
2014-02-27T15:46:43.796-08:00| vmx| I120+ This host supports Intel VT-x, but Intel VT-x is disabled.
2014-02-27T15:46:43.796-08:00| vmx| I120+ Intel VT-x might be disabled if it has been disabled in the BIOS/firmware settings or the host has not been power-cycled since changing this setting.
2014-02-27T15:46:43.796-08:00| vmx| I120+ (1) Verify that the BIOS/firmware settings enable Intel VT-x and disable 'trusted execution.'
2014-02-27T15:46:43.796-08:00| vmx| I120+ (2) Power-cycle the host if either of these BIOS/firmware settings have been changed.
2014-02-27T15:46:43.796-08:00| vmx| I120+ (3) Power-cycle the host if you have not done so since installing VMware Fusion.
2014-02-27T15:46:43.796-08:00| vmx| I120+ (4) Update the host's BIOS/firmware to the latest version.
2014-02-27T15:46:43.796-08:00| vmx| I120+ For more detailed information, see http://vmware.com/info?id=152.
2014-02-27T15:46:43.796-08:00| vmx| I120: ----------------------------------------

That reminded me that I had turned off the VT-x setting in the bios as that was recommended to improve performance on my hackintosh. Hope that helps anyone else who runs into this problem.

[Sapphire64]

It may be helpful: had the same error. GUI launch changed message to "Unknown error". Been caused because in vagrantfile there were specified more resources than my machine had.

So had to fix this part:

  config.vm.provider "vmware_fusion" do |fusion|
    fusion.vmx["memsize"] = "2048"
    fusion.vmx["numvcpus"] = "2"
  end

[berinle]

@Sapphire64 thanks for the code snippet. Just hit this as well on an older iMac while trying to run the normad getting started vagrant file. Limiting the amount of cpus fixed the issue.

[nickithewatt]

This may be helpful for some so adding a note here.
My case is actually slightly different, I was trying to use the remote packer build option for a vmware-iso builder in Atlas (https://atlas.hashicorp.com) and got the dreaded "The operation was canceled" message.

The helpful guys from Atlas support referrenced this ticket, which alerted me to the fact that I too was indeed asking for more resources (vcpus) for my VM to start up, than the Atlas environment had been allocated for the build.

Modifying packer from this:

  "vmx_data": {
    "cpuid.coresPerSocket": "1",
    "memsize": "1024",
    "numvcpus": "2"
  },
  . . .

to this:

  "vmx_data": {
    "cpuid.coresPerSocket": "1",
    "memsize": "1024",
    "numvcpus": "1"
  },
  . . .

which sorted it out!

[duvey]

Running Windows 10 - re-activating Intel Virtualisation Technology (which I had previously disabled) in the BIOS solved this for me.

[szeitlin]

Having the same problem on Mac (Yosemite, version 10.10.5) with vmware-fusion. The weird thing is, I have two vagrants. One works, and one doesn't. The Vagrantfile is the same, but on the one that's not working, I'm getting this same error, e.g.

An error occurred while executing `vmrun`, a utility for controlling
VMware machines. The command and output are below:

Command: ["start", "/Users/.../Ubuntu 64-bit.vmx", "nogui", {:notify=>[:stdout, :stderr], :timeout=>45}]

Stdout: 2016-03-24T17:09:38.153| ServiceImpl_Opener: PID 31138
Error: The operation was canceled

I tried decreasing the number of cores and the allocated memory, but that didn't seem to make any difference. Tried adding the v.gui = true line, didn't give me any more useful output.

Previously had two vagrants working on virtualbox with separate Vagrantfiles, separate databases, port-forwarding to different ports. Would like to do something similar on vmware-fusion. Help?

[Jalle19]

I'm getting the same thing when building with Packer on Atlas. I've already changed the vmx_data to just once core per socket and in total, doesn't help.

[szeitlin]

interestingly, now my other vagrant is also broken. I tried vagrant up --debug --provider vmware_fusion which gave me the much more verbose output:

ERROR vagrant: /Users/Sighten/.vagrant.d/gems/gems/vagrant-vmware-fusion-4.0.2/lib/vagrant-vmware-fusion/driver.rb:616:in `block (2 levels) in vmrun'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/retryable.rb:17:in `retryable'
/Users/Sighten/.vagrant.d/gems/gems/vagrant-vmware-fusion-4.0.2/lib/vagrant-vmware-fusion/driver.rb:613:in `block in vmrun'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/busy.rb:19:in `busy'
/Users/Sighten/.vagrant.d/gems/gems/vagrant-vmware-fusion-4.0.2/lib/vagrant-vmware-fusion/driver.rb:612:in `vmrun'
/Users/Sighten/.vagrant.d/gems/gems/vagrant-vmware-fusion-4.0.2/lib/vagrant-vmware-fusion/driver.rb:440:in `start'
/Users/Sighten/.vagrant.d/gems/gems/vagrant-vmware-fusion-4.0.2/lib/vagrant-vmware-fusion/action_farm.rb:38:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/Users/Sighten/.vagrant.d/gems/gems/vagrant-vmware-fusion-4.0.2/lib/vagrant-vmware-fusion/action_farm.rb:331:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:160:in `handle'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:42:in `block in call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/environment.rb:516:in `lock'

(and many more lines of traceback)

At this point I'm suspecting that I have multiple vagrants already running, so I'm going to try checking for that, i.e. https://github.com/mitchellh/vagrant/issues/910

[szeitlin]

vagrant global-status shows I have 2 suspended and 1 running vagrant. Looks like one of them can't be halted b/c the original working directory was moved (this was after I had tried to vagrant up and it threw an error, so it didn't occur to me that it had actually succeeded).

I had to actually copy the folder back to where it had been, and then I was able to vagrant destroy using the id. Then I was able to vagrant up my previously-working vagrant again. Suspended that. Went back to the one that was failing and now I'm getting a more useful error message about incorrect configuration.

[ccope]

I have a few hundred users running vagrant + vmware fusion and vmrun:... Operation Canceled is one of the most frequent errors I deal with. A couple more reasons that this happens:

• A vmdk attached to the VM is corrupt (have to destroy the vmdk)
• The vmware kernel module gets into a bad state (have to reboot)
• Not enough free memory on the host

[szeitlin]

@ccope I never did figure out how to get 2 vagrants to work with vmware fusion, mostly because I ran into a problem with redis and didn't have the bandwidth to try switching to two instances of that (changing the ports did not fix it).

[eightsixeight]

same issu here, it seems windows 10 decided to run an update and reboot while machine was vagrant upped... now in logs
disk.vmdk' has internal consistency errors that might be caused by partial corruption of the disk file. It is recommended that you restore a backup of this virtual machine. If you do not have a backup, VMware Workstation can repair the disk, but there is a possibility that the data on the disk may be corrupt and affect the stability of the guest.
2017-04-08T08:25:20.683-04:00| vmx| I125+ Do you wish to repair the disk and continue?

[ccope]

For users who aren't aware and stumble across this issue, the vmware log file is located in .vagrant/machines/$machine_name/vmware/$random_uuid/vmware.log (where .vagrant is usually located in the same folder as your Vagrantfile). It sometimes contains more useful error messages than the GUI.

[geckoseo]

For anyone else who stumbles on this is the same way I did, the problem surfaced after attempting to get Docker for Windows running in order to move away from VM Machines to Docker Containers.

After failing to get a stable environment working in Windows 10 with Docker, I decided to uninstall Docker for now and revert to Vagrant until the integration between Docker and Windows 10 is a bit more mature.

This is when the error described in this issue surfaced.

An error occurred while executing vmrun, a utility for controlling
VMware machines. The command and output are below:

Command: ["start", "/Users/.../Ubuntu 64-bit.vmx", "nogui", {:notify=>[:stdout, :stderr], :timeout=>45}]

Stdout: xxxxx| ServiceImpl_Opener: PID 31138
Error: The operation was canceled

In Windows it isn't possible to run VMware or Virtualbox in parallel with Docker, because Docker for Windows requires Hyper-V to be enabled.

In my case, the problem was actually being caused by Credential Guard, and was a hangover from Hyper-V being started.

After removing Docker, and even though the Hyper-V services had been stopped, and all the Docker networks had been deleted, there was a Feature still running called "Isolated User Mode".

Turning off Isolated User Mode disables Credential Guard, and restores the ability for Vagrant to start up.

I did not need to touch my virtual disks, everything that was previously installed in the Vagrant boxes was fine. No drastic measures required.

So the problem in this case was not related to VMware at all really, and was being caused by Hyper-V, and the fact that Docker doesn't clean up after itself properly after uninstallation.

In both cases, what is being described here is a problem that appears to exist in both Mac and Windows, and the common factor appears to be Vagrant. Perhaps the correlation is coincidental...

[Orpere]

An error occurred while executing vmrun, a utility for controlling
VMware machines. The command and output are below:

Command: ["start", "/Users/Orlando/Documents/Ansible_course/.vagrant/machines/app02/vmware_fusion/b1bd5377-2d5d-4731-8f38-d5cb761d6ca3/Xenial.vmx", "nogui", {:notify=>[:stdout, :stderr], :timeout=>45}]

Stdout: 2017-08-18T02:11:56.990| ServiceImpl_Opener: PID 464
Error: The operation was canceled

Stderr:
my still like this the vagrant is so unstable

[ccope]

@Orpere and anyone else who has trouble with this error, please check the log file mentioned in https://github.com/mitchellh/vagrant/issues/8465 (and if it helps you, give that issue a :+1: ). If that doesn't help, you should open a new issue with a link to this one, and say whether you have been able to start a VM using the VMware GUI. (Hashicorp probably doesn't follow conversations happening in closed issues)

[Orpere]

I just fix mine
I have removed all fusion settings and replace hostmanager plugin for vagrant-hostsupdater
and now all work just fine
thanks

[meawoppl]

I am using a free trial to eval VMWare-workstation and I had to run vmware and agree to the trial. Worked afterward.

[josezenem]

Two of us ran into this issue, and we solved it in 2 different ways.

1. Launched VMWare and made a random Ubuntu Server Image which prompted "Permissions" for VMWare under "Security & Privacy", this solved the issue for one of us.
2. We looked at @ccope solution and looked at the log file, we simply lowered the memory since the machine didn't have enough to boot up.

[hashibot[bot]]

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.