Vagrant: O plugin VMware Fusion detecta o endereço IP errado do vmrun cmd

Criado em 23 nov. 2015 · 3Comentários · Fonte: hashicorp/vagrant

Tenho um problema com o VMware Fusion 7.1.3, Vagrant 1.7.4 e o plugin vagrant-vmware-fusion 4.0.2 ao se comunicar com uma VM TP4 do Windows Server 2016 por meio do WinRM.

Parece que o plugin vagrant-vmware-fusion pega o endereço IP errado 172.16.0.1 da VM, que é apenas um switch virtual.

É assim que parece girar a VM do Windows:

$ vagrant up
Bringing machine 'default' up with 'vmware_fusion' provider...
==> 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: WinRM address: 172.16.0.1:5985
    default: WinRM username: vagrant
    default: WinRM transport: plaintext
^C==> default: Waiting for cleanup before exiting...

Dentro da VM, tenho as seguintes placas de rede:

PS C:\Users\vagrant> ipconfig

Windows IP Configuration


Ethernet adapter vEthernet (Virtual Switch):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::851b:ed4b:1436:4710%11
   IPv4 Address. . . . . . . . . . . : 172.16.0.1
   Subnet Mask . . . . . . . . . . . : 255.240.0.0
   Default Gateway . . . . . . . . . :

Ethernet adapter Ethernet 2:

   Connection-specific DNS Suffix  . : localdomain
   Link-local IPv6 Address . . . . . : fe80::91d4:5359:785b:e075%8
   IPv4 Address. . . . . . . . . . . : 192.168.254.134
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.254.2

Tunnel adapter isatap.{F8AB9E14-C9C4-4A78-A4F9-966B59BD5D9E}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter isatap.localdomain:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : localdomain

Esta é uma VM TP4 do Windows 2016 com Windows Docker instalado e Hyper-V. A instalação do Windows docker cria esse switch virtual. E, de alguma forma, a placa de rede VMware "primária" é chamada de "Ethernet 2" e não a primeira da lista.

Executando o mesmo vagrant up com o log de depuração mostra que o endereço IP correto 192.168.254.134 é capturado em primeiro lugar, mas após executar o vmrun getGuestIPAddress que retorna o endereço IP do switch virtual Vagrant então usa este endereço IP errado para WinRM.

$ "/Applications/VMware Fusion.app/Contents/Library/vmrun" "getGuestIPAddress" "/Users/stefan/code/docker-windows-box/.vagrant/machines/default/vmware_fusion/e04a32bc-9b7a-4cbf-9abb-dc5e7f299af7/packer-vmware-iso.vmx"
172.16.0.1

Portanto, como vmrun parece recuperar valores errados em algumas situações, seria uma ideia melhor usar apenas o endereço IP da primeira correspondência de endereço MAC?

Em algum lugar no meio do log de depuração, encontrei o endereço IP correto: https://gist.github.com/sethvargo/9a84345f4fafd1490f7e

bug providevmware

Fonte

StefanScherer

Comentários muito úteis

Olá @StefanScherer - apresentamos uma opção de configuração para tentar resolver situações como esta ... você pode tentar isso em seu Vagrantfile?

config.vm.provider "vmware_fusion" do |v|
  v.enable_vmrun_ip_lookup = false
end

phinze em 23 nov. 2015

🎉2

Todos 3 comentários

Olá @StefanScherer - apresentamos uma opção de configuração para tentar resolver situações como esta ... você pode tentar isso em seu Vagrantfile?

config.vm.provider "vmware_fusion" do |v|
  v.enable_vmrun_ip_lookup = false
end

phinze em 23 nov. 2015

🎉2

@phinze Muito obrigado! Sim, isso fez isso!

$ vagrant up
Bringing machine 'default' up with 'vmware_fusion' provider...
==> 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: WinRM address: 192.168.254.134:5985
    default: WinRM username: vagrant
    default: WinRM transport: plaintext
==> default: Machine booted and ready!
==> default: Forwarding ports...
    default: -- 3389 => 3389
    default: -- 22 => 2222
    default: -- 5985 => 55985
    default: -- 5986 => 55986
==> default: Configuring network adapters within the VM...
==> default: Configuring secondary network adapters through VMware 
==> default: on Windows is not yet supported. You will need to manually
==> default: configure the network adapter.
==> default: Enabling and configuring shared folders...
    default: -- /Users/stefan/code/docker-windows-box: /vagrant
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.

Embora eu dê uma olhada nas notas de lançamento do plug-in de vez em quando, não entendi este.

StefanScherer em 23 nov. 2015

Apenas para registro, este é meu Vagrantfile usado para Windows Server 2016 TP4 para executá-lo em tela cheia no modo retina em um MBP.

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"

Vagrant.require_version ">= 1.6.0"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box          = "windows_2016_tp4"
  config.vm.communicator = "winrm"

  ["vmware_fusion", "vmware_workstation"].each do |provider|
    config.vm.provider provider do |v, override|
      v.gui = true
      v.vmx["memsize"] = "4096"
      v.vmx["numvcpus"] = "2"
      v.vmx["vhv.enable"] = "TRUE"
      v.vmx["hypervisor.cpuid.v0"] = "FALSE"
      v.enable_vmrun_ip_lookup = false
    end
  end

  config.vm.provider "vmware_fusion" do |v|
    v.vmx["gui.fitguestusingnativedisplayresolution"] = "TRUE"
    v.vmx["mks.enable3d"] = "TRUE"
    v.vmx["mks.forceDiscreteGPU"] = "TRUE"
    v.vmx["gui.fullscreenatpoweron"] = "TRUE"
    v.vmx["gui.viewmodeatpoweron"] = "fullscreen"
    v.vmx["gui.lastPoweredViewMode"] = "fullscreen"
    v.vmx["sound.startconnected"] = "TRUE"
    v.vmx["sound.present"] = "TRUE"
    v.vmx["sound.autodetect"] = "TRUE"
  end

  config.vm.provision "shell", path: "scripts/provision.ps1", privileged: false
end

StefanScherer em 23 nov. 2015

Esta página foi útil?

0 / 5 - 0 avaliações