I’m trying to boot up a vEOS switch in VirtualBox via Vagrant. I’ve tried both new and old vEOS versions, but I hang here:
==> eos: Waiting for machine to boot. This may take a few minutes…
nxosv boxes also fail, cumulus and Ubuntu boxes come up fine.
macOS: Mojave 10.14.3
I don’t see a problem booting 4.21.1F, but there is a long pause at the same stage you see vagrant hanging while the vm boots.
Have you tried adding this to your VagrantFile to monitor the console of the vm during bootup? That might help show where things break.
Sorry to just give you a “works for me”
$ vagrant ssh eos
Arista Networks EOS shell
Software image version: 18.104.22.168F
Uptime: 0 weeks, 0 days, 0 hours and 2 minutes
This stopped working for me after upgrading VirtualBox to the same version as you have.
I have problems using vagrant on virtualbox, too. When booting more than a single vEOS-lab instance, there is an Error:
Stderr: VBoxManage.exe: error: NamedPipe#0 failed to create named pipe \.pipevEOS-build-serial (VERR_PIPE_BUSY)
I tried virtualbox images from vEOS-lab-4.20.10M as well as vEOS-lab-22.214.171.124F. virtualbox version is 5.2.30 r130521 (Qt5.6.2), Vagrant version 2.2.4. Both installed on a Windows 10 system.
Anyone similar issues? Any cheats to resolve?
That usually happens if you use multiple vagrant files. It’s recommended to define all your VMs within one Vagrantfile and deploy it like that. There’s a good example on the following github page: https://github.com/michaelc0n/vagrant-veos/blob/master/Vagrantfile (credit to Michael Saenz)
Thanks, Tamas, for your answer. Unfortunately, this is not the case. Definition of virtual machines is located in a single Vagrantfile and even using the examle out of git (I tried the example with bowtieing four vEOS Switches together) I get the similar error.
Hm. Some more suggestions?
I’ve found the issue! vagrant was automatically trying to use the same serial port for all VMs, which is not possible, hence it was complaining that \.pipevEOS-build-serial is busy (VERR_PIPE_BUSY), because it was already locked by the first VM that was brought up. You can also check the same if you go to VirtualBox, click on the VM, select settings, go to Serial Ports and you’ll see that both VMs will have the same path address ,which is wrong..
spine01.vm.provider “virtualbox” do |v|
With that I was able to bring up multiple VMs.
FYI I had issues with the net-ssh module, so after bringing up each VM, I had to use ‘vagrant up’ once or twice for the next one to start
Hope this helps,
Post your Answer
You must be logged in to post an answer.