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-esxi "Failed, timeout waiting for "running"." #134

Open
mplinuxgeek opened this issue Aug 20, 2018 · 5 comments
Open

vmware-esxi "Failed, timeout waiting for "running"." #134

mplinuxgeek opened this issue Aug 20, 2018 · 5 comments

Comments

@mplinuxgeek
Copy link

mplinuxgeek commented Aug 20, 2018

vagrant up fails when using vmware-esxi plugin.

The error is caused because the plugin is waiting for the VM state to change to running which it never does because there are no VMware tools in the image.

I logged into the image via ESXi console and installed and started open-vm-tools, after this has been done vagrant successfully provisions the new VM.

I can test this with VMware workstation when I get to work tomorrow, but I can't test Fusion or vCenter however I expect they will all behave the same.

vagrant@vmtest01:~/vmmgt01$ vagrant up --provider=vmware_esxi

Bringing machine 'vmmgt01' up with 'vmware_esxi' provider...
==> vmmgt01: Virtual Machine will be built.
VMware ovftool 4.3.0 (build-7948156)
==> vmmgt01: ---   --- ESXi Summary ---
==> vmmgt01: --- ESXi host       : X.X.X.X
==> vmmgt01: --- Virtual Network : ["LAN"]
==> vmmgt01: --- Disk Store      : datastore1
==> vmmgt01: --- Resource Pool   : /
==> vmmgt01: ---  --- Guest Summary ---
==> vmmgt01: --- VM Name         : vmmgt01
==> vmmgt01: --- Box             : centos/7
==> vmmgt01: --- Box Ver         : 1804.02
==> vmmgt01: --- Memsize (MB)    : 4096
==> vmmgt01: --- CPUS            : 2
==> vmmgt01: --- Guest OS type   : linux
==> vmmgt01: ---   --- Guest Build ---
Opening VMX source: /home/vagrant/.vagrant.d/boxes/centos-VAGRANTSLASH-7/1804.02/vmware_desktop/ZZZZ_vmmgt01.vmx
Opening VI target: vi://[email protected]:443/
Deploying to VI: vi://[email protected]:443/
Transfer Completed                    
Completed successfully
==> vmmgt01: --- VMID            : 48
==> vmmgt01: --- VM has been Powered On...
==> vmmgt01: --- Waiting for state "running"
There was an error.
  Failed, timeout waiting for "running".

Update:
I wrote a quick script to check if the server is running in VMware if yes then install and start open-vm-tools, perhaps this could be added to the image on first boot? or as a @reboot cron job that deletes itself after the first run?

#!/bin/bash
if dmidecode -s system-product-name | grep --quiet -i vmware; then
  yum install -y open-vm-tools
  systemctl enable vmtoolsd.service
  systemctl start vmtoolsd.service
fi
@lpancescu
Copy link
Contributor

@mplinuxgeek sorry for taking so long to answer, lots of things to do lately.

I've never added open-vm-tools explicitly to the images because they used to be part of the default installation, or maybe I misremember. Unfortunately, we haven't had anybody volunteering to test our VMware or Hyper-V images for quite a while. I think we could just add the packages to the Vagrant images unconditionally, vmtoolsd will just exit if it can't detect VMware.

lpancescu added a commit to lpancescu/sig-cloud-instance-build that referenced this issue Aug 28, 2018
@mvermaes
Copy link
Contributor

At least from September 2016, I think open-vm-tools has not been preinstalled in the box. Will be great to see it included.

The Tools aren't actually required to use 'stock' Vagrant (ie. just Workstation and Fusion with rsync), other than to get bidirectional synced folder support. But like you said, I think it should be safe to include them, and it seems like it would also resolve the vmware-esxi plugin issue that @mplinuxgeek reported.

I still do what I can to test the VMware images in Fusion when there is a new box release btw :)

@lpancescu
Copy link
Contributor

@mvermaes Hi, glad to hear you're still using our images! I haven't heard anything from you in a while. We skipped releasing the last 1-2 monthly images due to apparent XFS corruption in the libvirt images (not yet understood - the VirtualBox images are ok, though). This is also why the automatic tests are failing on my PR for this issue. Would you be willing to test the VMware images if I email you the links?

@mplinuxgeek
Copy link
Author

@lpancescu thank you, I like to use direct from source images where possible, it's great to see CentOS providing official images.

@mvermaes
Copy link
Contributor

@lpancescu Sure thing, email them through.

kbsingh pushed a commit that referenced this issue Sep 30, 2018
* Aligned armhfp ks on the x86_64 one

* Add architecture to basesearch for i386 image

* Set the default IO scheduler to noop (#124)

The best IO scheduler for a VM is noop, not the default cfq.  We have to
send the disk sectors to be written or read as fast as possible to the
host OS, which is the only one able to optimize and reorder the disk
operations considering the needs of all hosted VMs and other
applications that might be running.

The RedHat documentation also recommends noop for guest VMs, unless they
use dedicated raw partitions (not the case for Vagrant images).

* Add open-vm-tools to the images

Fixes issue #134

* Do not add open-vm-tools to centos/6

The package appears not to exist in CentOS Linux 6.

* Use the proper syntax for the services line
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants