As the title might suggest, this article is not about the infamous glasses (or wear-a-smartphone-in-front-of-your-eyes-thingamajig). It's about a virtual development environment on your desktop and the steps you need to take in order to get things up and running. There's no guarantee that the described solutions are generic, but it's a fallback in case my memory fails and I don't want to reinvent the wheel again (and again).
I use Vagrant for these 'boxes'. I'm a MacFan myself, so using Apple OS X El Capetan gets me up and running very quick. But business wise Microsoft Windows is our weapon of choice. A couple of months ago, using Windows 7, Vagrant 1.6 and Virtual Box 4.3, there wasn't a thunder cloud in the sky. But hey, we're techies so upgrade to the latest and the greatest please! And then the amazement commences. Updating the stack to Windows 10 (mind you that I did start out with almost a clean install), Vagrant 1.8 and VirtualBox 5.0 posed some challenges. Starting by not being able to download the given vagrantbox.
D:\Develop\ubuntu>vagrant init ubuntu/trusty64
A 'Vagrantfile' has been placed in this directory. You are now
ready to 'vagrant up' your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
'vagrantup.com' for more information on using Vagrant.
D:\Develop\ubuntu>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'ubuntu/trusty64' could not be found. Attempting to find and install...
default: Box Provider: virtualbox
default: Box Version: >= 0`
`The box 'debian/jessie64' could not be found or`
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
'vagrant login'. Also, please double-check the name. The expanded
URL and error message are shown below:
URL: ["https://atlas.hashicorp.com/ubuntu/trusty64"]
Error:
Using the most popular search engine on the web learned that you need Microsoft Visual C++ Redistributable (the one from 2010, because the 2012 version was already on the machine as a dependency for mRemoteNG ;-). Installing it brought us a step further but then I was stopped by a timeout, which leaves Vagrant in the dark about the virtual machine status.
D:\Develop\ubuntu>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/trusty64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: There was a problem while downloading the metadata for your box
==> default: to check for updates. This is not an error, since it is usually due
==> default: to temporary network problems. This is just a warning. The problem
==> default: encountered was:
==> default:
==> default:
==> default:
==> default: If you want to check for box updates, verify your network connection
==> default: is valid and try again.
==> default: Setting the name of the VM: ubuntu2_default_1457593474553_89798
==> 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 (guest) => 2222 (host) (adapter 1)
==> 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
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.
Because Vagrant runs VirtualBox in headless mode, you can't see what's happening, which is easily solved by adding
config.vm.provider :virtualbox do |vb|
vb.gui = true
end
to the Vagrantfile. It's probably already in there, so removing the comment character in front of these lines will suffice. First thing you notice is the following alertbox and the corresponding Vagrant error message:
D:\Develop\ubuntu>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: A newer version of the box 'ubuntu/trusty64' is available! You currently
==> default: have version '20160304.0.0'. The latest is version '20160304.0.1'. Run
==> default: `vagrant box update` to update.
==> 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 (guest) => 2222 (host) (adapter 1)
==> 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
The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'starting, running'. The machine is in the
'paused' state. Please verify everything is configured
properly and try again.
If the provider you're using has a GUI that comes with it,
it is often helpful to open that and watch the machine, since the
GUI often has more helpful error messages than Vagrant can retrieve.
For example, if you're using VirtualBox, run `vagrant up` while the
VirtualBox GUI is open.
The primary issue for this error is that the provider you're using
is not properly configured. This is very rarely a Vagrant issue.
Helpful error message there are, but first things first: the alertbox. In order to suppress this message you'll need to enable hyperthreading or virtualization technology through the BIOS of your PC. Next to that the Hyper-V at ‘Windows-features on- or off’ must be checked. Follow the instructions on this site. Restarting your PC several times is part of the procedure ;-). Finally we can tackle the final hurdle, by looking at the VirtualBox console. Seems that this Vagrantbox ubuntu/trusty64 has a network anomaly. Just to be sure issue a vagrant destroy before the vagrant up and you'll notice the following:
Dan ben je er bijna. Zekerheidshalve even een vagrant destroy uitvoeren, gevolgd door de vagrant up. In mijn geval resulteerde dat in een time-out.
Doordat de GUI van de virtual box zichtbaar was, kon ik het opstartproces volgen. Onze Vagrant box ubuntu/trusty64 lijkt last te hebben van een netwerk-anomalie.
cloud-init-nonet[4.54]: waiting 10 seconds for network device
cloud-init-nonet[14.57]: waiting 120 seconds for network device
cloud-init-nonet[134.57]: gave up waiting for a network device.
This means back to the Vagrantfile and tell it we want to use the AMD instead of the Intel network adapter (NIC).
config.vm.provider "virtualbox" do |vb|
### Change network card to PCnet-FAST III
# For NAT adapter
vb.customize ["modifyvm", :id, "--nictype1", "Am79C973"]
# For host-only adapter
vb.customize ["modifyvm", :id, "--nictype2", "Am79C973"]
end
In the end the specified Vagrantbox will fire up. You'll get the usual SSH timeout, so if you're a perfectionist, just optimize theconfig.ssh.timeout.
Nota Bene: vagrant ssh doesn't work out of the Windows OS box. Using the output Vagrant gives you when you issue this command, can off course be used in a SSH client like PuTTY. Or you install Git with options (Unix Tools), so you can control Vagrant fully from the command line. As you can see a working virtual environment has some burdens to overcome. There are probably some other (hardware) dependencies we did not encounter. Also does the mixture of 32 and 64-bit not always turn out right. And last but not least the variety of Vagrantboxes each with their own peculiarities. All in all, this article feels like a decent reminder to fall back on.
Used links: