esxi-vagrant

esxi-vagrant copied to clipboard

Running latest vagrant and vagrant-libvirt plugin, i fail to bring up the example, because apparently it trys to use sudo during provision step even tho the privileged option is enabled. It seems this happens during the insecure key replacement exchange:

==> esxi: Running provisioner: shell...
 INFO environment: Running hook: provisioner_run
 INFO runner: Running action: provisioner_run #<Method: Vagrant::Action::Builtin::Provision#run_provisioner(env) /opt/vagrant/embedded/gems/2.2.19/gems/vagrant-2.2.19/lib/vagrant/action/builtin/provision.rb:137>
 INFO warden: Calling IN action: #<Proc:0x00007f98416c8e60 /opt/vagrant/embedded/gems/2.2.19/gems/vagrant-2.2.19/lib/vagrant/action/warden.rb:126 (lambda)>
DEBUG ssh: Checking key permissions: /home/abi/esxi-vagrant/example/.vagrant/machines/esxi/libvirt/private_key
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: chown -R root /tmp/vagrant-shell (sudo=true)
DEBUG ssh: stderr: sh: sudo: not found

DEBUG ssh: Exit status: 127

NM, thats not the issue. The Main issue is that the esxi ssh connection resets:

==> esxi: Running provisioner: shell...
 INFO environment: Running hook: provisioner_run
 INFO runner: Running action: provisioner_run #<Method: Vagrant::Action::Builtin::Provision#run_provisioner(env) /opt/vagrant/embedded/gems/2.2.19/gems/vagrant-2.2.19/lib/vagrant/action/builtin/provision.rb:137>
 INFO warden: Calling IN action: #<Proc:0x00007f98416c8e60 /opt/vagrant/embedded/gems/2.2.19/gems/vagrant-2.2.19/lib/vagrant/action/warden.rb:126 (lambda)>
DEBUG ssh: Checking key permissions: /home/abi/esxi-vagrant/example/.vagrant/machines/esxi/libvirt/private_key
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: chown -R root /tmp/vagrant-shell (sudo=true)
DEBUG ssh: stderr: sh: sudo: not found

DEBUG ssh: Exit status: 127
DEBUG ssh: Uploading: /tmp/vagrant-shell20220509-2454889-1ikvmvg to /tmp/vagrant-shell
DEBUG ssh: Re-using SSH connection.
DEBUG ssh: Ensuring remote directory exists for destination upload
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mkdir -p "/tmp" (sudo=false)
DEBUG ssh: stderr: 41e57d38-b4f7-4e46-9c38-13873d338b86-vagrant-ssh
DEBUG ssh: Exit status: 0
DEBUG ssh: Uploading file /tmp/vagrant-shell20220509-2454889-1ikvmvg to remote /tmp/vagrant-shell
 INFO interface: detail: Running: inline script
 INFO interface: detail:     esxi: Running: inline script
    esxi: Running: inline script
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: chmod +x '/tmp/vagrant-shell' && /tmp/vagrant-shell (sudo=false)
DEBUG ssh: stderr: 41e57d38-b4f7-4e46-9c38-13873d338b86-vagrant-ssh
 INFO interface: detail: Connection failed
 INFO interface: detail:     esxi: Connection failed
    esxi: Connection failed
DEBUG ssh: Exit status: 1
ERROR warden: Error occurred: The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

it works if using two steps:

vagrant up --no-provision vagrant provision

Sorry, but that never happened here, and I'm not sure what is going on, since sudo is not supposed to be used at all.

Maybe we should not install the vagrant ssh key in the base image?

While trying https://github.com/rgl/esxi-vagrant/pull/9 I can see this happening in my local environment too.

It seems that something is restarting the guest ssh server and/or the guest network while vagrant is still using the ssh connection.

I'm afraid that vagrant does not have a generic way (that I'm aware of) of waiting for the guest to be in a ready state, e.g. execute a script inside the guest, and only proceed when that script runs successfully (and keep retrying regardless of the status of the ssh connection).

I'm not sure when I going to be able to find/implement a proper solution. This also means that I will not merge #9 until this issue is fixed.

hi,

yesi agree, seems to be related to the new version, not quite sure what triggers the reset. Not sure if there is an option to make vagrant not attempting to reuse the existing connection (which exists for the winrm backend)