Hashicorp Packer hyper-v builder not getting SSH address - hashicorp-packer

Building a Ubuntu 22.04 server image with the Hyper-V builder for Packer.
Packer however never seems to find the IP address of the machine.
==> hyperv-iso: Starting HTTP server on port 8882
==> hyperv-iso: Creating switch 'public' if required...
==> hyperv-iso: switch 'public' already exists. Will not delete on cleanup...
==> hyperv-iso: Creating virtual machine...
2022/12/12 20:01:40 packer.exe plugin: No existing virtual harddrive, not attaching.
==> hyperv-iso: Enabling Integration Service...
==> hyperv-iso: Mounting os dvd drive C:/Tools/ubuntu_server.iso ...
2022/12/12 20:01:50 packer.exe plugin: No floppy disk, not attaching.
==> hyperv-iso: Skipping mounting Integration Services Setup Disk...
2022/12/12 20:01:50 packer.exe plugin: No CD files specified. CD disk will not be made.
==> hyperv-iso: Mounting secondary DVD images...
==> hyperv-iso: Configuring vlan...
==> hyperv-iso: Determine Host IP for HyperV machine...
==> hyperv-iso: Host IP for the HyperV machine: 192.168.1.111
==> hyperv-iso: Attempting to connect with vmconnect...
==> hyperv-iso: Starting the virtual machine...
==> hyperv-iso: Waiting 10s for boot...
==> hyperv-iso: Typing the boot command...
............................. (removed the boot command).........................
2022/12/12 20:02:17 packer.exe plugin: [DEBUG] Unable to get address during connection step: No ip address.
==> hyperv-iso: Waiting for SSH to become available...
2022/12/12 20:02:17 packer.exe plugin: [INFO] Waiting for SSH, up to timeout: 20m0s
2022/12/12 20:02:22 packer.exe plugin: [DEBUG] Error getting SSH address: No ip address.
The installation completes but an address for Packer to SSH against is never discovered. The machine does get an IP address however and I can manually SSH to it.
According to the documentation Packer should automatically attach the 'Integration Services Setup Disk' but the log says that it is skipping it, guessing this is the issue? But I cannot find a way to fix it.

Related

Chef Kitchen Vagrant box will not start when adding additional disks

Development is happening on Mac OSX
Writing a cookbook to partition, format, mount drives dynamically based on drives that are not partitioned, mounted, or formatted, May have been taken out of single drive raid-0 configuration, or may not have been configured through raid controller yet...
While working on writing test cases for cookbook. I am having the following issues.
.kitchen.yml file:
driver:
name: vagrant
# ssh:
# insert_key: false
customize:
cableconnected1: 'on'
createhd:
- filename: /tmp/disk1.vdi
size: 128
storagectl:
- name: SATA Controller
portcount: 4
storageattach:
- storagectl: SATA Controller
port: 0
device: 0
type: hdd
medium: /tmp/disk1.vdi
privileged: true
Command: kitchen verify
Gets stuck at the following
Output:
-----> Starting Kitchen (v1.20.0)
$$$$$$ Deprecated configuration detected:
require_chef_omnibus
Run 'kitchen doctor' for details.
-----> Creating <default-centos-7>...
(erb):173: warning: constant ::Fixnum is deprecated
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'bento/centos-7'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'bento/centos-7' is up to date...
==> default: Setting the name of the VM: default-centos-
7_default_1526333511693_18382
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 (guest) => 2200 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few
minutes...
default: SSH address: 127.0.0.1:2200
default: SSH username: vagrant
default: 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.
Will not proceed any further. The adding disk code was taken directly from the kitchen-vagrant documentation for adding a disk.
I can remove the createhd, storagectl, & storageattach sections, at which point the vagrant box works as intended.
I have verified that the /tmp/disk1.vdi file is created, I also have to delete the file between runs, after a kitchen destroy else I get the following error:
-----> Starting Kitchen (v1.20.0)
$$$$$$ Deprecated configuration detected:
require_chef_omnibus
Run 'kitchen doctor' for details.
-----> Creating <default-centos-7>...
(erb):173: warning: constant ::Fixnum is deprecated
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'bento/centos-7' is up to date...
==> default: Machine not provisioned because `--no-provision` is
specified.
Waiting for SSH service on 127.0.0.1:2200, retrying in 3 seconds
It will continue being stuck on retying in 3 seconds indefinitely until I escape the command.
I have tried with and without:
ssh:
insert_key: false
I have tried different formats of files that vagrant is supposed to support as a disk, including .vdi, .vmdk
I have ensured that SATA Controller is the appropriate controller available for the box.
This seems issue with vagrant and virtualbox versions. You can find a similar issue here
The reason for this is that kitchen/vagrant tries to bind the OS disk to port 0 of your controller. So the reason it doesn't boot is because there is no boot disk bound!
If you change port: 0 to port: 1 in your example it should boot as expected.

Vagrant + Hyper V IPV6 addresses Assigned

I have been having a lot of troubles with Vagrant 2.0.1 on Windows 10 with Hyper V.
When I do vagrant up I receive an ipv6 address. Which chef can't access and fails to provision the virtual:
Bringing machine 'default' up with 'hyperv' provider...
==> default: Verifying Hyper-V is enabled...
==> default: Configured startup memory is 2048
==> default: Configured cpus number is 2
==> default: Importing a Hyper-V instance
default: Cloning virtual hard drive...
default: Creating and registering the VM...
default: Setting VM Integration Services
default: Successfully imported a VM with name: vargrant-dev-source
==> default: Installing Chef cookbooks with Librarian-Chef...
==> default: Auto-generating node name for Chef...
==> default: Starting the machine...
==> default: Waiting for the machine to report its IP address...
default: Timeout: 120 seconds
default: IP: fe80::215:5dff:fe02:f5a
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: fe80::215:5dff:fe02:f5a:22
default: SSH username: vagrant
default: SSH auth method: private key
... Eventually times out here ....
I used the following commands to set up a NATed switch:
New-VMSwitch –SwitchName “NATSwitch” –SwitchType Internal
New-NetIPAddress –IPAddress 172.21.21.1 -PrefixLength 24 -InterfaceAlias "vEthernet (NATSwitch)"
New-NetNat –Name MyNATnetwork –InternalIPInterfaceAddressPrefix 172.21.21.0/24
Interestingly everything works the first time I set up the VM switch and I get a valid IPV4 address and things are okay. But after I reboot the virtual machines will only ever get IPV6 addresses and I cant access existing ones created before the reboot.
My vagrant file:
Vagrant.configure("2") do |config|
config.vm.provider "hyperv"
config.vm.box = "maxx/ubuntu16"
config.vm.boot_timeout = 2000
config.vm.network "private_network", ip: "172.21.21.2"
... general config omitted.
end
I have tried both DHCP and static and both seem to fail. With static IP seemingly ignored completely.
Any ideas what I'm missing or doing wrong? (I am using a wifi connection if that is relevant)
I found a way around it by using internet connection sharing between my wifi and the virtual hyper v network. But currently, there is a bug in windows build 1607 where internet connection sharing needs to be restarted after every reboot.
A large thread here on the MS forums:
https://answers.microsoft.com/en-us/windows/forum/windows_10-networking/ics-internet-connection-sharing-dosent-work-in/a203c90f-1214-4e5e-ae90-9832ae5ceb55

Vagrant/virtualbox no SSH connection and timeout (Windows)

I a trying to setup this machine: https://github.com/ByteInternet/hypernode-vagrant
When I do vagrant up i get following error: Timed out while waiting for the machine to boot.
Full context of the error:
$ vagrant up
Bringing machine 'hypernode' up with 'virtualbox' provider...
==> hypernode: Will use PHP 7. If you want PHP 5.5 instead change the php version in local.yml.
==> hypernode: Checking if box 'hypernode_php7' is up to date...
==> hypernode: Clearing any previously set forwarded ports...
==> hypernode: Clearing any previously set network interfaces...
==> hypernode: Preparing network interfaces based on configuration...
hypernode: Adapter 1: nat
hypernode: Adapter 2: hostonly
==> hypernode: Forwarding ports...
hypernode: 80 (guest) => 8080 (host) (adapter 1)
hypernode: 3306 (guest) => 3307 (host) (adapter 1)
hypernode: 22 (guest) => 2222 (host) (adapter 1)
==> hypernode: Running 'pre-boot' VM customizations...
==> hypernode: Booting VM...
==> hypernode: Waiting for machine to boot. This may take a few minutes...
hypernode: SSH address: 127.0.0.1:2222
hypernode: SSH username: vagrant
hypernode: 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.
When I boot the VM manually, I can see the networking is not working as it should be. There is no connection. When I change the VM's settings to bridged network the networking does work. But the vagrant is configured as NAT. So any changes I make in the settings or in the vagrant file seem to be resetting back.
I tried Vagrant 1.9.3, 1.9.2 and 1.9.0 on two different PC's. I am using Virtualbox 5.1.18. When I filter down the logs with "NAT" is see following errors (this is not the complete log, only a small portion):
00:00:00.575454 SUP: Loaded VMMR0.r0 (C:\Program Files\Oracle\VirtualBox\VMMR0.r0) at 0xfffff80c897b0000 - ModuleInit at fffff80c897d3590 and ModuleTerm at fffff80c897d3a80 using the native ring-0 loader
00:00:01.681747 Driver = "NAT" (cb=4)
00:00:01.962037 SUP: Loaded VBoxDDR0.r0 (C:\Program Files\Oracle\VirtualBox\VBoxDDR0.r0) at 0xfffff80c898d0000 - ModuleInit at 0000000000000000 and ModuleTerm at 0000000000000000 using the native ring-0 loader
00:00:02.196495 NAT: Guest address guess set to 10.0.2.15 by initialization
00:00:02.204465 NAT: DNS#0: 192.168.178.1
00:00:02.271317 NAT: Failed to redirect TCP 127.0.0.1:2222 -> 0.0.0.0:22 (Unknown error)
00:00:02.271732 NAT: Failed to redirect TCP 0.0.0.0:3307 -> 0.0.0.0:3306 (Unknown error)
00:00:02.272033 NAT: Failed to redirect TCP 0.0.0.0:2200 -> 0.0.0.0:80 (Unknown error)
00:00:09.976199 NAT: Link up
00:00:39.428974 NAT: DHCP offered IP address 10.0.2.15
00:00:39.429404 NAT: DHCP offered IP address 10.0.2.15
00:03:02.167191 NAT: DHCP offered IP address 10.0.2.15
00:03:02.167820 NAT: DHCP offered IP address 10.0.2.15
00:07:58.531621 NAT: Zone(nm:mbuf_cluster, used:0)
00:07:58.532221 NAT: Zone(nm:mbuf_packet, used:0)
00:07:58.532232 NAT: Zone(nm:mbuf, used:1)
00:07:58.532419 NAT: Zone(nm:mbuf_jumbo_pagesize, used:0)
00:07:58.532961 NAT: Zone(nm:mbuf_jumbo_9k, used:0)
00:07:58.533255 NAT: Zone(nm:mbuf_jumbo_16k, used:0)
00:07:58.533424 NAT: Zone(nm:mbuf_ext_refcnt, used:0)
00:07:58.536529 Changing the VM state from 'DESTROYING' to 'TERMINATED'
How can I solve or debug this?
UPDATE
Last couple of days I also retried with different version of virtualbox and Vagrant listed below without any results:
Virtualbox 5.0.18
Virtualbox 5.0.20
Virtualbox 5.0.36
Vagrant 1.9.3
I also tried another box, which has the same problem. So it seems it's not the box but the host.
Furthermore I tried a setup on a Windows 7 machine with exactly the same results. I think I am missing something in the configuration but I don't know what since there is not a definitive guide to get this working on a Windows machine.
UPDATE 2: Could it be possible the machines I try this on do not support this kind of a setup? I tried looking for virtualizations options in the BIOS.
UPDATE 3: When I do ssh -v 127.0.0.1 -p 1222 from my host to the guest I get following error. SSH service is up and running on the guest. I checked with sshd service status.
$ ssh -v 127.0.0.1 -p 1222
OpenSSH_7.3p1, OpenSSL 1.0.2k 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 1222.
debug1: connect to address 127.0.0.1 port 1222: Connection refused
ssh: connect to host 127.0.0.1 port 1222: Connection refused
UPDATE 4: I cannot ping any internet IP's or domains from the guest machine.
UPDATE 5: SOLVED! Switched to Linux for quite a while now. Best decision ever :D
First of al, changing the first interface to NAT is normal behavior. It's a requirement in order to make vagrant work.
You can check two things:
1) preferences > network > nat-network. (settings should be like this):
network settings
2) make sure you're virtual cable is connected
cable connected
3) maybe you can try another vagrant box.
When I have this error on Windows 10 Pro:
...
homestead: SSH auth method: private key
Timed out while waiting for the machine to boot. ...
...
I have found that all I need to do is have the VirtualBox GUI open and the VM selected while running this on a command line:
vagrant reload --provision
If the GUI is closed, it repeatedly times out that throws the error above.
If the GUI is opened, then the process continues as normal with no errors, and everything starts working.
I have also found that sometimes after automatic Windows restarts, my network adapter does not have the VirtualBox NDIS6 Bridged Networking Driver installed, and that can also cause this error.
This can be fixed by opening the network connection properties and clicking Install -> Service -> Oracle Corporation -> VirtualBox NDIS6 Bridged Networking Driver to install the driver.
It should just appear in the list without having to go through a driver install, but if you somehow never had that driver installed before, then this might put you through a driver install process.
On Windows, the typical path to the folder with that driver in it is below. You probably won't have to manually install anything, but in case you do, open that folder and then Right-Click -> Install the VBoxNetFlt.inf file.
%ProgramFiles%\Oracle\VirtualBox\drivers\network\netflt

Launching a Vagrant VM inside Travis-CI

How do you launch a Virtualbox VM using Vagrant inside Travis-CI?
I know launching a VM inside a VM is sometimes not supported, but there have been reported successes with this specific configuration.
I'm trying to setup a continuous integration server to run unittests for my sysadmin tool, to test it across different operating systems and Python versions. It uses Tox to handle initializing the various Python virtual environments and Pytest to run the tests and wrap Vagrant to setup and teardown the Virtualbox VM. It runs fine on my Ubuntu 14 localhost, but in Travis, Vagrant times out trying to boot a Virtualbox VM:
==> default: Importing base box 'ubuntu/trusty64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: Setting the name of the VM: functional_tests_default_1463515960654_71459
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
...
The job exceeded the maximum time limit for jobs, and has been terminated.
Since it's not giving me any details, I'm not sure how to diagnose the problem. I tried to enable more output with export VAGRANT_LOG=DEBUG; but that didn't show anything useful and exceeded Travis's maximum log size. I also tried increasing the timeout, and the memory allocation to 1GB, but neither helped.
The only odd thing I've noticed, that I've not been able to explain, is this message from sudo apt-get -y install -q virtualbox-ose-dkms virtualbox --fix-missing:
Module build for the currently running kernel was skipped since the
kernel source for this kernel does not seem to be installed.
However, immediately before this, the command to install kernel source succeeds:
sudo apt-get -y --force-yes install linux-headers-`uname -r`
How do you launch a Vagrant/Virtualbox VM inside Travis-CI?
Sadly this is not supported by Travis-CI and there's no plan to do it in the near future. Check the following ticket: https://github.com/travis-ci/travis-ci/issues/6060
Since Travis is running your build in a virtualized container (OpenVZ) you could try with a 32-bit VM. That could work, but I haven't tested.
From the end of 2019 it is possible to run Vagrant on TravisCI! All you have to do, is to switch to libvirt & KVM provider instead of virtualbox on Travis - see this so answer for a complete HowTo and this fully comprehensible example project on GitHub: https://github.com/jonashackt/vagrant-travisci-libvrt
See this TravisCI build for example:
If you don't want to use the libvirt provider locally, you can simply use one of the generic Vagrant Box images from Vagrant Cloud, since they support both virtualbox (locally) and libvirt (on TravisCI).

Vagrant tries to force WinRM with windows guest when I specify ssh should be used

I have a windows guest with cygwin and openssh installed, with user/password configured in the Vagrantfile. When I run vagrant up, everything works until "configuring and enabling network interfaces", at which point it barfs and complains about winrm being required for windows vagrant boxes:
==> default: Waiting for domain to get an IP address...
==> default: Waiting for SSH to become available...
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...
==> default: Waiting for SSH to become available...
==> default: Creating shared folders metadata...
==> default: Configuring and enabling network interfaces...
Configuring networks on Windows requires the communicator to be
set to WinRM. To do this, add the following to your Vagrantfile:
config.vm.communicator = "winrm"
Note that the Windows guest must be configured to accept insecure
WinRM connections, and the WinRM port must be forwarded properly from
the guest machine. This is not always done by default.
How can I get it to stop doing this?

Resources