Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vmware provider is not using static ip #5461

Closed
apackeer opened this issue Mar 12, 2015 · 3 comments
Closed

Vmware provider is not using static ip #5461

apackeer opened this issue Mar 12, 2015 · 3 comments

Comments

@apackeer
Copy link

Hi,

The VMWare provider is not using the static IP set. Seems to be a regression of #5006

Vagrant version: 1.7.2
Vagrant-vmware-fusion: 3.2.4
Vmware Fusion Professional 7.1.1 (2498930)
Mac OSX Yosemite

Vagrantfile:

Vagrant.configure(2) do |config|
  config.vm.synced_folder ".", "/vagrant", disabled: true
  config.vm.box = "chef/ubuntu-14.04"
  config.vm.network :public_network, ip: "192.168.1.17"
end

Results in:

➜  test2  vagrant up --provider=vmware_fusion
Bringing machine 'default' up with 'vmware_fusion' provider...
==> default: Cloning VMware VM: 'chef/ubuntu-14.04'. This can take some time...
==> default: Checking if box 'chef/ubuntu-14.04' is up to date...
==> default: Verifying vmnet devices are healthy...
==> default: Preparing network adapters...
==> default: Starting the VMware VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 192.168.14.129:22
    default: SSH username: vagrant
    default: SSH auth method: private key
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if its present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Forwarding ports...
    default: -- 22 => 2222
==> default: Configuring network adapters within the VM...
➜  test2  vagrant ssh
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-32-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
Last login: Sat Jan 31 16:00:50 2015 from 172.16.230.1
vagrant@vagrant:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0c:29:73:7a:36
          inet addr:192.168.14.129  Bcast:192.168.14.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe73:7a36/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:519 errors:0 dropped:0 overruns:0 frame:0
          TX packets:365 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:64318 (64.3 KB)  TX bytes:53582 (53.5 KB)

eth1      Link encap:Ethernet  HWaddr 00:0c:29:73:7a:40
          inet addr:192.168.1.192  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe73:7a40/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1419 (1.4 KB)  TX bytes:1392 (1.3 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:16 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1184 (1.1 KB)  TX bytes:1184 (1.1 KB)

Turn on debugging, what i can find relevant:

EBUG network: Available slots for high-level adapters: #<Set: {1, 2, 3, 4, 5, 6, 7, 8}>
 INFO network: Determining network adapters required for high-level configuration...
 INFO network:  -- Slot 1: bridged
 INFO network: Determining adapters and compiling network configuration...
 INFO network: Slot 0. Type: nat
DEBUG network: Normalized configuration: {:auto_config=>false, :type=>:dhcp}
DEBUG network: Adapter configuration: {:type=>:nat, :slot=>0}
DEBUG network: Network configuration: {:type=>:dhcp, :auto_config=>false}
 INFO network: Slot 1. Type: bridged
DEBUG network: Normalized configuration: {:auto_config=>true, :mac=>nil, :type=>:dhcp, :ip=>"192.168.1.17", :protocol=>"tcp", :id=>"9c6dd3f3-4336-4305-aa6a-1cc6378dda26"}
DEBUG network: Adapter configuration: {:type=>:bridged, :mac_address=>nil, :slot=>1}
DEBUG network: Network configuration: {:auto_config=>true, :mac=>nil, :netmask=>"255.255.255.0", :type=>:dhcp, :ip=>"192.168.1.17", :protocol=>"tcp", :id=>"9c6dd3f3-4336-4305-aa6a-1cc6378dda26"}
 INFO network: Enabling 2 adapters...

Type above shows dhcp AND ip....

@nevir
Copy link

nevir commented Mar 24, 2015

I'm seeing the same thing w/ the coreos image (http://beta.release.core-os.net/amd64-usr/current/coreos_production_vagrant_vmware_fusion.json)

Interestingly, it seems to pin the first 3 octets of my specified IP. Only the last octet is randomized (and it seems to prefer 127 when it can get it).

@frizop
Copy link

frizop commented Mar 28, 2015

Iirc, this was an issue with VMware Fusion itself. Is this now a supported feature?

Original issue: #4184

@mitchellh
Copy link
Contributor

This is fixed

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants