vagrant ssh auth error : Timed out while waiting for the machine to boot

[jeenhyung]

I have a server with Centos 7(VPS hosting), Virtualbox 5.0 and Vagrant 1.8.1.
I'm trying to run "vagrant up".
I'd like to deploy coreos with vagrant.

I get this message:

    ==> core-01: Attempting graceful shutdown of VM...
        core-01: Guest communication could not be established! This is usually because
        core-01: SSH is not running, the authentication information was changed,
        core-01: or some other networking issue. Vagrant will force halt, if
        core-01: capable.
    ==> core-01: Forcing shutdown of VM...
    ==> core-01: Clearing any previously set forwarded ports...
    ==> core-01: Fixed port collision for 22 => 2222. Now on port 2202.
    ==> core-01: Clearing any previously set network interfaces...
    ==> core-01: Preparing network interfaces based on configuration...
        core-01: Adapter 1: nat
        core-01: Adapter 2: hostonly
    ==> core-01: Forwarding ports...
        core-01: 22 (guest) => 2202 (host) (adapter 1)
    ==> core-01: Running 'pre-boot' VM customizations...
    ==> core-01: Booting VM...
    ==> core-01: Waiting for machine to boot. This may take a few minutes...
        core-01: SSH address: 127.0.0.1:2202
        core-01: SSH username: core
        core-01: SSH auth method: private key
    Timed out while waiting for the machine to boot. This means that
    Vagrant was unable to communicate with the guest machine within
    the configured ("config.vm.boot_timeout" value) time period.

    If you look above, you should be able to see the error(s) that
    Vagrant had when attempting to connect to the machine. These errors
    are usually good hints as to what may be wrong.

    If you're using a custom box, make sure that networking is properly
    working and you're able to connect to the machine. It is a common
    problem that networking isn't setup properly in these boxes.
    Verify that authentication configurations are also setup properly,
    as well.

    If the box appears to be booting properly, you may want to increase
    the timeout ("config.vm.boot_timeout") value.

---

my Vagrant file :

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

    require 'fileutils'

    Vagrant.require_version ">= 1.6.0"

    CLOUD_CONFIG_PATH = File.join(File.dirname(__FILE__), "user-data")
    CONFIG = File.join(File.dirname(__FILE__), "config.rb")

    # Defaults for config options defined in CONFIG
    $num_instances = 1
    $instance_name_prefix = "core"
    $update_channel = "alpha"
    $image_version = "current"
    $enable_serial_logging = false
    $share_home = false
    $vm_gui = false
    $vm_memory = 1024
    $vm_cpus = 1
    $shared_folders = {}
    $forwarded_ports = {}

    # Attempt to apply the deprecated environment variable NUM_INSTANCES to
    # $num_instances while allowing config.rb to override it
    if ENV["NUM_INSTANCES"].to_i > 0 && ENV["NUM_INSTANCES"]
      $num_instances = ENV["NUM_INSTANCES"].to_i
    end

    if File.exist?(CONFIG)
      require CONFIG
    end

    # Use old vb_xxx config variables when set
    def vm_gui
      $vb_gui.nil? ? $vm_gui : $vb_gui
    end

    def vm_memory
      $vb_memory.nil? ? $vm_memory : $vb_memory
    end

    def vm_cpus
      $vb_cpus.nil? ? $vm_cpus : $vb_cpus
    end

    Vagrant.configure("2") do |config|
      # always use Vagrants insecure key
      config.ssh.insert_key = false

      config.ssh.username="core"

      config.vm.box = "coreos-%s" % $update_channel

      config.vm.box_check_update = false

      if $image_version != "current"
          config.vm.box_version = $image_version
      end
      config.vm.box_url = "https://storage.googleapis.com/%s.release.core-os.net/amd64-usr/%s/coreos_production_vagrant.json" % [$update_channel, $image_version]

      ["vmware_fusion", "vmware_workstation"].each do |vmware|
        config.vm.provider vmware do |v, override|
          override.vm.box_url = "https://storage.googleapis.com/%s.release.core-os.net/amd64-usr/%s/coreos_production_vagrant_vmware_fusion.json" % [$update_channel, $image_version]
        end
      end

      config.vm.provider :virtualbox do |v|
        # On VirtualBox, we don't have guest additions or a functional vboxsf
        # in CoreOS, so tell Vagrant that so it can be smarter.
        v.check_guest_additions = false
        v.functional_vboxsf     = false

        # Change network card to PCnet-FAST III
        # For NAT adapter
        v.customize ["modifyvm", :id, "--nictype1", "Am79C973"]
        # For host-only adapter
        v.customize ["modifyvm", :id, "--nictype2", "Am79C973"]
        v.memory = "1024"

        #v.gui = true
      end

      # plugin conflict
      if Vagrant.has_plugin?("vagrant-vbguest") then
        config.vbguest.auto_update = false
      end

      (1..$num_instances).each do |i|
        config.vm.define vm_name = "%s-%02d" % [$instance_name_prefix, i] do |config|
          config.vm.hostname = vm_name

          if $enable_serial_logging
            logdir = File.join(File.dirname(__FILE__), "log")
            FileUtils.mkdir_p(logdir)

            serialFile = File.join(logdir, "%s-serial.txt" % vm_name)
            FileUtils.touch(serialFile)

            ["vmware_fusion", "vmware_workstation"].each do |vmware|
              config.vm.provider vmware do |v, override|
                v.vmx["serial0.present"] = "TRUE"
                v.vmx["serial0.fileType"] = "file"
                v.vmx["serial0.fileName"] = serialFile
                v.vmx["serial0.tryNoRxLoss"] = "FALSE"
              end
        end

        config.vm.provider :virtualbox do |vb, override|
              vb.customize ["modifyvm", :id, "--uart1", "0x3F8", "4"]
              vb.customize ["modifyvm", :id, "--uartmode1", serialFile]
            end
          end

          if $expose_docker_tcp
            config.vm.network "forwarded_port", guest: 2375, host: ($expose_docker_tcp + i - 1), auto_correct: true
          end

          $forwarded_ports.each do |guest, host|
            config.vm.network "forwarded_port", guest: guest, host: host, auto_correct: true
          end

          ["vmware_fusion", "vmware_workstation"].each do |vmware|
            config.vm.provider vmware do |v|
              v.gui = vm_gui
              v.vmx['memsize'] = vm_memory
              v.vmx['numvcpus'] = vm_cpus
            end
          end

          config.vm.provider :virtualbox do |vb|
            vb.gui = vm_gui
            vb.memory = vm_memory
            vb.cpus = vm_cpus
          end

          ip = "172.17.8.#{i+100}"
          config.vm.network :private_network, ip: ip

          # Uncomment below to enable NFS for sharing the host machine into the coreos-vagrant VM.
          #config.vm.synced_folder ".", "/home/core/share", id: "core", :nfs => true, :mount_options => ['nolock,vers=3,udp']
          $shared_folders.each_with_index do |(host_folder, guest_folder), index|
            config.vm.synced_folder host_folder.to_s, guest_folder.to_s, id: "core-share%02d" % index, nfs: true, mount_options: ['nolock,vers=3,udp']
          end

          if $share_home
            config.vm.synced_folder ENV['HOME'], ENV['HOME'], id: "home", :nfs => true, :mount_options => ['nolock,vers=3,udp']
          end

          if File.exist?(CLOUD_CONFIG_PATH)
            config.vm.provision :file, :source => "#{CLOUD_CONFIG_PATH}", :destination => "/tmp/vagrantfile-user-data"
            config.vm.provision :shell, :inline => "mv /tmp/vagrantfile-user-data /var/lib/coreos-vagrant/", :privileged => true
        end

        end
      end
    end

---

How can I fix it? Thanks.

[sethvargo]

Hi @jeenhyung

Thank you for opening an issue, and I am sorry this is causing you problems. There are a number of external variables in your Vagrantfile, and I tried to reduce them. I am unable to reproduce this using the following Vagrantfile:

$update_channel = "alpha"
$image_version = "current"

Vagrant.configure("2") do |config|
  config.ssh.insert_key = false

  config.ssh.username = "core"

  config.vm.box = "coreos-%s" % $update_channel

  config.vm.network :private_network, ip: "172.17.8.100"

  config.vm.hostname = vm_name

  config.vm.provider :virtualbox do |v, o|
    o.vm.box_url = "https://storage.googleapis.com/%s.release.core-os.net/amd64-usr/%s/coreos_production_vagrant.json" % [$update_channel, $image_version]

    # On VirtualBox, we don't have guest additions or a functional vboxsf
    # in CoreOS, so tell Vagrant that so it can be smarter.
    v.check_guest_additions = false
    v.functional_vboxsf     = false

    # Change network card to PCnet-FAST III
    # For NAT adapter
    v.customize ["modifyvm", :id, "--nictype1", "Am79C973"]

    # For host-only adapter
    v.customize ["modifyvm", :id, "--nictype2", "Am79C973"]
  end

  ["vmware_fusion", "vmware_workstation"].each do |vmware|
    config.vm.provider vmware do |v, o|
      o.vm.box_url = "https://storage.googleapis.com/%s.release.core-os.net/amd64-usr/%s/coreos_production_vagrant_vmware_fusion.json" % [$update_channel, $image_version]
    end
  end
end

Could you please give it a try? If you do not see the issue reproduce, then there is something in your configuration (perhaps in the config file or perhaps a vm-level configuration) that is causing this, not Vagrant.

If the issue persists, please put the debug log in a github gist and link here. Thanks! 😄

[sethvargo]

Hi there,

I am going to close this due to lack of response. If this is still occurring, please open a new issue and include the answers to the queries above as well as complete the new issue template that will appear when you submit an issue. Thanks! 😄

[ameyaagashe]

Hi Guys, I am having the exact same issue.

C:\Users\jim_000\VirtualBox VMs\load_balancer_lab>vagrant up
Bringing machine 'lb1' up with 'virtualbox' provider...
Bringing machine 'web1' up with 'virtualbox' provider...
Bringing machine 'web2' up with 'virtualbox' provider...
==> lb1: Checking if box 'centos/7' is up to date...
==> lb1: Clearing any previously set forwarded ports...
==> lb1: Fixed port collision for 22 => 2222. Now on port 2200.
==> lb1: Clearing any previously set network interfaces...
==> lb1: Preparing network interfaces based on configuration...
    lb1: Adapter 1: nat
==> lb1: Forwarding ports...
    lb1: 22 (guest) => 2200 (host) (adapter 1)
==> lb1: Running 'pre-boot' VM customizations...
==> lb1: Booting VM...
==> lb1: Waiting for machine to boot. This may take a few minutes...
    lb1: SSH address: 127.0.0.1:2200
    lb1: SSH username: vagrant
    lb1: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

C:\Users\jim_000\VirtualBox VMs\load_balancer_lab>

Please find attached my vagrant file. I have reinstalled vagrant and virtual box but still no charm

Please rename Vagrantfile.txt to Vagrantfile

Many Thanks in advance.

Vagrantfile.txt

[sadeq786]

Any luck figuring this out?

[aidygus]

Having the same issue trying to start a Windows 2012 R2 guest on Windows 7.

I'm using vagrant 1.8.6 and VMWare workstation Pro 12 (12.5.0 build-4352439).

Console output
Here is a copy of the vmware.log
Copy of my Vagrantfile

[sadeq786]

Restart your computer and keep hitting f10 key. This will take you into the system BIOS. There you can check if your Hyper-Virtualization is disabled. If so, change it to Enabled, save and continue to restart your PC. This is what I did to make it work and it fixed the problem in 2 minutes. Let me know if it worked.

[aidygus]

I've looked deeper into this and I think I've found what's causing my issues. Don't know if it's relevant to the original poster but may help others out there.

Running the vms on virtualbox is not a problem and everything starts fine. It's just VMWare that the issue is with. The only physical difference between VB and VMw is that VM uses vmdk and VB vdi extensions.

This lead me to examine the vmware.log file a little closer and tail it (or get-content in this case). There is a stage where the console reports Starting the VMware VM... and stops for about a minute and a half before continuing with what appears to be buffered responses from vagrant.

The line it stops at is :
2016-10-31T15:37:37.792Z| vmx| I125: DISK: OPEN 'C:\Users\myuser\VM\pipeline\vagrant_sql\.vagrant\machines\sqlserver\vmware_workstation\8a1bdd5c-b0e9-4ca7-83ca-59416cb7afd0\2012R2_VM-disk1.vmdk' Geo (5221/255/63) BIOS Geo (5221/255/63)

After the pause the following lines state :
`2016-10-31T15:37:37.860Z| vmx| I125: DISKUTILWIN32: DiskUtilW32IsATASSDDevice: Reported rotation rate = 5400

2016-10-31T15:37:37.861Z| vmx| I125: DISK: Opening disks took 84003 ms.
`

It's taking vmware 84 seconds to open the disks.

I came across this article and I monitored the processes. Our development machines have sophos installed and sure enough the sophos spiked and is causing vagrant not to get access to the disk until it's finished scanning.

Adding vmdk to the whitelist fixed the problem and now disks are starting in under 500ms and it's starting correctly

[RiaParshina]

I have the same issue every time I shut down my machine without saving a state (without using vagrant halt command). In this case I go to VirtualBox UI, find my machine, right click on it and choose Strat->Headless start. Then the machine is running I save its state, but don't stop it completely. After that I get back to terminal/console and 'vagrant up' normally. Sometimes I need to start the machine from the UI several times.

[ghost]

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.