Kitchen unable to log in to the VM it creates.
NZenitram opened this issue · 3 comments
Versions:
- Version of kitchen-vcenter: 2.0.0
- Version of test-kitchen: 1.22
- Version of chef: 3.1.0
Platform Details
- Version of vCenter: 6.7
- Version of ESXi: 6.7
Scenario:
Test kitchen creates the VM on the ESXi Host using the vCenter driver. However, kitchen login and kitchen converge fail at login.
$ kitchen login -l debug
D Berksfile found at /Users/<name>/chef/cookbooks/<cookbook>/Berksfile, loading Berkshelf
D Berkshelf 7.0.4 library loaded
D Login command: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=VERBOSE -p 22 ubuntu@ (Options: {})
The ssh command is missing the IP/FQDN/Hostname?
$ kitchen converge
-----> Starting Kitchen (v1.22.0)
-----> Converging <default-ubuntu-1604>...
Preparing files for transfer
Preparing dna.json
Resolving cookbook dependencies with Berkshelf 7.0.4...
Removing non-cookbook files before transfer
Preparing data_bags
Preparing nodes
Preparing validation.pem
Preparing client.rb
ubuntu@'s password:
Two things on converge:
- Not sure why isn't prompting for a password
ubuntu@without an IP or FQDN shows up again when it does
On converge it is prompting for a password even with the transport block:
driver:
name: vcenter
vcenter_username: <username@vpshere.local>
vcenter_password: <%= ENV['TF_VAR_UPW'] %>
vcenter_host: <%= ENV['TF_VAR_VS'] %>
vcenter_disable_ssl_verify: true
provisioner:
name: chef_zero
sudo_command: sudo
deprecations_as_errors: true
retry_on_exit_code:
- 35 # 35 is the exit code signaling that the node is rebooting
max_retries: 2
wait_for_retry: 90
log_level: :debug
verifier:
name: inspec
platforms:
- name: ubuntu-16.04
driver_config:
targethost: <host>
template: ubuntu/test-kitchen-16.04
datacenter: <dc>
resource_pool: <pool>
transport:
username: "ubuntu"
password: "password"
Steps to Reproduce:
Create kitchen.yml as shown above and attempt to create and login to the VM using kitchen
Expected Result:
The VM will be created, you will be able to SSH into that VM through the CLI, but kitchen will fail.
Actual Result:
Unsure?
Maybe the hostname/IP is not being passed to Kitchen:
https://github.com/test-kitchen/test-kitchen/blob/1265f531744fa3d179b6fc8d86eab9d49070aa04/lib/kitchen/transport/ssh.rb
def login_command
args = %w{ -o UserKnownHostsFile=/dev/null }
args += %w{ -o StrictHostKeyChecking=no }
args += %w{ -o IdentitiesOnly=yes } if options[:keys]
args += %W{ -o LogLevel=#{logger.debug? ? 'VERBOSE' : 'ERROR'} }
if options.key?(:forward_agent)
args += %W{ -o ForwardAgent=#{options[:forward_agent] ? 'yes' : 'no'} }
end
if ssh_gateway
gateway_command = "ssh -q #{ssh_gateway_username}@#{ssh_gateway} nc #{hostname} #{port}"
args += %W{ -o ProxyCommand=#{gateway_command} -p #{ssh_gateway_port} }
end
Array(options[:keys]).each { |ssh_key| args += %W{ -i #{ssh_key} } }
args += %W{ -p #{port} }
args += %W{ #{username}@#{hostname} }
LoginCommand.new("ssh", args)
end
I see one reference to IP address in the gem in the create method:
new_vm = Support::CloneVm.new(connection_options, options)
new_vm.clone
state[:hostname] = new_vm.ip
state[:vm_name] = new_vm.name
I need some help figuring out how to debug gems before I can be of more assistance. If anyone has some time to lend in teaching me how to navigate gems in this fashion, I would appreciate it and may be able to help develop this in the future.
I used your kitchen.yml and substituted the placeholders with the data in my lab environment & added a suite. Sadly (for purpose of this issue) all worked as expected:
driver:
name: vcenter
vcenter_username: "administrator@vsphere.local"
vcenter_password: <password>
vcenter_host: "vcsa1.v670.lab.local"
vcenter_disable_ssl_verify: true
provisioner:
name: chef_zero
sudo_command: sudo
deprecations_as_errors: true
retry_on_exit_code:
- 35 # 35 is the exit code signaling that the node is rebooting
max_retries: 2
wait_for_retry: 90
log_level: :debug
verifier:
name: inspec
platforms:
- name: ubuntu-16.04
driver_config:
targethost: esx1.v670.lab.local
template: 'templates/ubuntu18-template'
datacenter: 'Datacenter'
resource_pool: 'kitchen'
transport:
username: "root"
password: "<sshpassword>"
suites:
- name: default
run_list:
- recipe[empty::default]
verifier:
inspec_tests:
- test/integration/default
Create:
# kitchen create
-----> Starting Kitchen (v1.23.2)
-----> Creating <default-ubuntu-1604>...
Cloning 'templates/ubuntu18-template' to create the VM...
Waiting for network interfaces to become available...
Finished creating <default-ubuntu-1604> (0m51.09s).
-----> Kitchen is finished. (1m8.81s)
Contents of the kitchen statefile in .kitchen/default-ubuntu-1604.yml:
---
hostname: 192.168.240.207
vm_name: default-ubuntu-16.04-9c5d2147
last_action: create
last_error:
SSH Login:
# kitchen login
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-43-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Last login: Thu Jan 10 16:56:35 2019 from 192.168.240.1
root@ubuntu:~#
Please ping me here when you're available for a chat on the Chef Community Slack to find your problem (I don't have that one open at home usually, but will see Github updates via mail). As soon as we figure it out, I can address this.
This was issue on my own workstation related to improperly updating my chef gems. Chef gems can be found /Users/<user>/.chefdk/gem/ruby/2.5.0/gems while ruby gems are found /usr/local/rvm/gems/ruby-2.5.1/gems/. I was updating the ruby gems by running gem update kitchen-vcenter and not the chef gems chef gem update kitchen-vcenter. In this case, simply updating the chef gem package solved the problem.
Check which version of the gem you are running /Users/<user>/.chefdk/gem/ruby/2.5.0/gems here. In my case I was still running 1.3.1. Simply running chef gem update solved this problem.