The VMware network device vmnet2 can't be started

[Curtis]

Any thoughts on this one?

==

$ vagrant up apis --provider=vmware_fusion
Bringing machine 'apis' up with 'vmware_fusion' provider...

[apis] Verifying vmnet devices are healthy...
The VMware network device 'vmnet2' can't be started because
its routes collide with another device: 'vboxnet'. Please
either fix the settings of the VMware network device or stop the
colliding device. Your machine can't be started while VMware
networking is broken.
 
#
# vagrant file
#
 
$ cat Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :
 
Vagrant.configure("2") do |config|

 
  config.vm.define :apis do |apis|
    apis.vm.box = "centos65fusion"

    #apis_config.vm.host_name = "apis"
    apis.vm.network :private_network, ip: "192.168.33.130"
    apis.vm.provider :vmware_fusion do |v|
      v.vmx["memsize"] = "2048"
    end
  end

 
end

==

Thanks,
Curtis.

--
Twitter: @serverascode
Blog: serverascode.com

[Mitchell Hashimoto]

Curtis,

VirtualBox hangs on to its network devices ("vboxnet") for dear life. I haven't figured out yet how to actually get rid of them except restarting your computer. 

Otherwise, change the private network IP to a different subnet.

Mitchell

--
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Curtis]

On Mon, Apr 8, 2013 at 3:33 PM, Mitchell Hashimoto <mitchell....@gmail.com> wrote:

Curtis,

VirtualBox hangs on to its network devices ("vboxnet") for dear life. I haven't figured out yet how to actually get rid of them except restarting your computer. 

Otherwise, change the private network IP to a different subnet.

Hmm, changing to a different subnet doesn't help. Guess I'll have to reboot...

Thanks,

Curtis.

[Trevor Roberts]

I tried changing the Subnets that my existing vmnets were using, and that worked for me...

[Curtis]

On Tue, Apr 9, 2013 at 7:29 AM, Trevor Roberts <vmtr...@gmail.com> wrote:

I tried changing the Subnets that my existing vmnets were using, and that worked for me...

Hmm, Ok, I had changed the subnet in the vagrant file I was using with vmware_fusion.

vmware_fusion is not working out like I'd hoped...

Thanks,

Curtis

 

--
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Mitchell Hashimoto]

Curtis,

I'm sorry! But please don't blame the provider, the issue is that the two hypervisors don't play nice together with their networking. It is a standard issue that would happen with any sort of combination of hypervisors. You must use distinct network interfaces otherwise they can't route to their own VMs. :)

[Curtis]

How about this? It's not a virtualbox device now...

$ vagrant up --provider=vmware_fusion

Bringing machine 'percona0' up with 'vmware_fusion' provider...

Bringing machine 'percona1' up with 'vmware_fusion' provider...

Bringing machine 'percona2' up with 'vmware_fusion' provider...

Bringing machine 'haproxy0' up with 'vmware_fusion' provider...

Bringing machine 'haproxy1' up with 'vmware_fusion' provider...

[percona0] Cloning Fusion VM: 'precise64'. This can take some time...

[percona0] Verifying vmnet devices are healthy...

The VMware network device 'vmnet1' can't be started because

its routes collide with another device: 'vmnet13'. Please

either fix the settings of the VMware network device or stop the

colliding device. Your machine can't be started while VMware

networking is broken.

==

And this was right after a reboot...

Thanks,

Curtis.

[Mitchell Hashimoto]

Curtis,

Hm, it might be easy to just clear out all the existing vmnet devices and start over. Maybe I should add a hidden command to do that. 

Anyways, can you get me the file contents of "/Library/Preferences/VMware\ Fusion/networking"

Best,

Mitchell

[Curtis]

On Thu, Apr 18, 2013 at 3:23 PM, Mitchell Hashimoto <mitchell....@gmail.com> wrote:

Curtis,

Hm, it might be easy to just clear out all the existing vmnet devices and start over. Maybe I should add a hidden command to do that. 

Anyways, can you get me the file contents of "/Library/Preferences/VMware\ Fusion/networking"

Here you go:

$ cat /Library/Preferences/VMware\ Fusion/networking

VERSION=1,0

answer VNET_10_DHCP yes

answer VNET_10_DHCP_CFG_HASH 1A21E888A905E39B922CB6D92FA4E8AFD6DAA26B

answer VNET_10_HOSTONLY_NETMASK 255.255.255.0

answer VNET_10_HOSTONLY_SUBNET 192.0.0.0

answer VNET_10_VIRTUAL_ADAPTER yes

answer VNET_11_DHCP yes

answer VNET_11_DHCP_CFG_HASH 68A99E8C498C8197835EB78E015DC1DD3CB9BC50

answer VNET_11_HOSTONLY_NETMASK 255.255.255.0

answer VNET_11_HOSTONLY_SUBNET 10.20.0.0

answer VNET_11_VIRTUAL_ADAPTER yes

answer VNET_12_DHCP yes

answer VNET_12_DHCP_CFG_HASH 7FABD62FCA75FD73362CECFA74AD902376B068CC

answer VNET_12_HOSTONLY_NETMASK 255.255.255.0

answer VNET_12_HOSTONLY_SUBNET 10.200.0.0

answer VNET_12_VIRTUAL_ADAPTER yes

answer VNET_13_DHCP yes

answer VNET_13_DHCP_CFG_HASH 5F0E2E7BDCF8E15408E0E84217CC047AE57903ED

answer VNET_13_HOSTONLY_NETMASK 255.255.0.0

answer VNET_13_HOSTONLY_SUBNET 172.16.0.0

answer VNET_13_VIRTUAL_ADAPTER yes

answer VNET_1_DHCP yes

answer VNET_1_DHCP_CFG_HASH 2DDDBBAE34AC633BB00FE0ED303D12A5F6CE2B9B

answer VNET_1_HOSTONLY_NETMASK 255.255.255.0

answer VNET_1_HOSTONLY_SUBNET 172.16.93.0

answer VNET_1_VIRTUAL_ADAPTER yes

answer VNET_2_DHCP yes

answer VNET_2_DHCP_CFG_HASH 02906B6214A172DBC3CA0225D1F2EBAD5EB98E4E

answer VNET_2_HOSTONLY_NETMASK 255.255.255.0

answer VNET_2_HOSTONLY_SUBNET 192.168.33.0

answer VNET_2_VIRTUAL_ADAPTER yes

answer VNET_3_DHCP yes

answer VNET_3_DHCP_CFG_HASH ECA49BB5A25F4677584FDFC0A0110DF6B22442EB

answer VNET_3_HOSTONLY_NETMASK 255.255.255.0

answer VNET_3_HOSTONLY_SUBNET 192.168.135.0

answer VNET_3_VIRTUAL_ADAPTER yes

answer VNET_4_DHCP yes

answer VNET_4_DHCP_CFG_HASH 6B729EFB930C7422BC5748334917444B65225F79

answer VNET_4_HOSTONLY_NETMASK 255.255.255.0

answer VNET_4_HOSTONLY_SUBNET 192.168.206.0

answer VNET_4_VIRTUAL_ADAPTER yes

answer VNET_5_DHCP yes

answer VNET_5_DHCP_CFG_HASH A6F051BDBEAA8D86F02F93B34D46C97D1CF2EB1B

answer VNET_5_HOSTONLY_NETMASK 255.255.255.0

answer VNET_5_HOSTONLY_SUBNET 10.0.5.0

answer VNET_5_VIRTUAL_ADAPTER yes

answer VNET_6_DHCP yes

answer VNET_6_DHCP_CFG_HASH BF60F3D7FDBB3D3FC4D26317D8E7E18C625939DB

answer VNET_6_HOSTONLY_NETMASK 255.255.0.0

answer VNET_6_HOSTONLY_SUBNET 172.10.0.0

answer VNET_6_VIRTUAL_ADAPTER yes

answer VNET_7_DHCP yes

answer VNET_7_DHCP_CFG_HASH C547F9624FAF1EE63FEF9C2BE3C6767919EB5CF2

answer VNET_7_HOSTONLY_NETMASK 255.255.0.0

answer VNET_7_HOSTONLY_SUBNET 10.10.0.0

answer VNET_7_VIRTUAL_ADAPTER yes

answer VNET_8_DHCP yes

answer VNET_8_DHCP_CFG_HASH D2C805562AA7834E92A09AC99FFDD5F5C2A6BB4A

answer VNET_8_HOSTONLY_NETMASK 255.255.255.0

answer VNET_8_HOSTONLY_SUBNET 192.168.134.0

answer VNET_8_NAT yes

answer VNET_8_VIRTUAL_ADAPTER yes

answer VNET_9_DHCP yes

answer VNET_9_DHCP_CFG_HASH 0267A54D69B8F9DFFA0D75861E6B18099074274A

answer VNET_9_HOSTONLY_NETMASK 255.255.255.0

answer VNET_9_HOSTONLY_SUBNET 10.0.0.0

answer VNET_9_VIRTUAL_ADAPTER yes

==

Thanks,

Curtis.

[Mitchell Hashimoto]

Curtis,

Yep, vmnet1 and vmnet13 definitely do collide. Do you have Fusion pro or Fusion regular? If you have Fusion pro, please open the network editor and remove all the networks to start over. If you have Fusion regular, you'll need to edit some files...

Get rid of all the lines in that file _except_ the ones that start with "answer VNET_1_" or "answer VNET_8_". We want to keep those, as they're the default networks that ship with Fusion. After that, open VMware Fusion.app, then run these commands in a separate terminal:

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --configure

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start

Then run 

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --status

And tell me the output. Should only have the vmnet1/vmnet8 devices. After THAT you shoudl be good to go again.

VMware networking is an absolute nightmare.

Best,

Mitchell

[Curtis]

On Thu, Apr 18, 2013 at 3:29 PM, Mitchell Hashimoto <mitchell....@gmail.com> wrote:

Curtis,

Yep, vmnet1 and vmnet13 definitely do collide. Do you have Fusion pro or Fusion regular? If you have Fusion pro, please open the network editor and remove all the networks to start over. If you have Fusion regular, you'll need to edit some files...

Get rid of all the lines in that file _except_ the ones that start with "answer VNET_1_" or "answer VNET_8_". We want to keep those, as they're the default networks that ship with Fusion. After that, open VMware Fusion.app, then run these commands in a separate terminal:

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --configure

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start

Then run 

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --status 

And tell me the output. Should only have the vmnet1/vmnet8 devices. After THAT you shoudl be good to go again.

$ sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --status

DHCP service on vmnet1 is running

Hostonly virtual adapter on vmnet1 is enabled

DHCP service on vmnet8 is running

NAT service on vmnet8 is running

Hostonly virtual adapter on vmnet8 is enabled

All the services configured on all the networks are running

 

VMware networking is an absolute nightmare.

Boy, you're telling me.

Thank you for the instructions.

Curtis.

 

Best,

Mitchell

[Mitchell Hashimoto]

Curtis,

Thinks look good. Phew. Can you try `vagrant up` again.

I'm going to try to think of ways to make this less of a nightmare for these edge cases like this.

Best,

Mitchell

--

[dan...@mangomint.com]

Tried the same steps, didn't resolve my issues... this is me after spending hours to fix this. I'm sick of this VMware provider now. Going back to VirtualBox.

[j weir]

On Monday, April 8, 2013 5:32:39 PM UTC-4, Curtis wrote:

$ vagrant up apis --provider=vmware_fusion
Bringing machine 'apis' up with 'vmware_fusion' provider...

[apis] Verifying vmnet devices are healthy...
The VMware network device 'vmnet2' can't be started because
its routes collide with another device: 'vboxnet'. Please
either fix the settings of the VMware network device or stop the
colliding device. Your machine can't be started while VMware
networking is broken.

When I come across this I use

sudo ifconfig vboxnet0 delete

sudo ifconfig vboxnet0 clear # this step might not be neccesary

Not a great fix and it might be best if your VirtualBox machine is not be running when you do this.

[elyob]

I am getting a similar message, although haven't installed virtualbox on this machine at all.

The VMware network device 'vmnet2' can't be started because

its routes collide with another device: 'en1'. Please

either fix the settings of the VMware network device or stop the
colliding device. Your machine can't be started while VMware
networking is broken.

If I disable my wi-fi 'en1' changes to ''.

This was all running fine for last few weeks. I did try to add a Cisco VPN to tunnel into work, but have since deleted this.

Will really appreciate info on how to fix this. I need this VM back up tomorrow morning.

[elyob]

FYI the instructions above worked. Reverting to vm 1 & 8 .. however, had to also change my IP on vagrant. Weird that this has all worked for a few weeks, and I don't have vbox on this machine.

[Adrian Simmons]

FYI the instructions above worked. Reverting to vm 1 & 8 .. however, had to also change my IP on vagrant. Weird that this has all worked for a few weeks, and I don't have vbox on this machine.

Did you just upgrade to mavericks? My ethernet PCI card stopped working when I upgraded, and am now using the built in ethernet instead - but because en0 changed device and MAC address vmware could be started until I reset the network devices. Point being that changes in the networking hardware, or even how OSX regards existing hardware can also cause this type of error.

[Nick Boyle]

Nope, this machine was a fresh installation of mavericks when I went SSD recently. It's been fine for a few weeks. I did try and add a VPN, but never connected to it.

On Mon, Dec 9, 2013 at 10:51 AM, Adrian Simmons <adr...@gmail.com> wrote:

FYI the instructions above worked. Reverting to vm 1 & 8 .. however, had to also change my IP on vagrant. Weird that this has all worked for a few weeks, and I don't have vbox on this machine.

Did you just upgrade to mavericks? My ethernet PCI card stopped working when I upgraded, and am now using the built in ethernet instead - but because en0 changed device and MAC address vmware could be started until I reset the network devices. Point being that changes in the networking hardware, or even how OSX regards existing hardware can also cause this type of error.

--
You received this message because you are subscribed to a topic in the Google Groups "Vagrant" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vagrant-up/DKxnHU4_aOg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vagrant-up+...@googlegroups.com.

[Jenny]

This didn't work for me, but when I explicitly open VMWare Fusion, quit, and then vagrant up again, the "'vmnet1' can't be started because its routes collide" problem goes away.