Vagrant error - A VirtualBox machine with the name already exists
Asked Answered
L

3

17

I want to use ubuntu/xenial64 box to create two separate VMs for two separate projects. I defined Vagrantfile in two separate project directories and added the line config.vm.box = "ubuntu/xenial64" to each.

The first box boots successfully. But when I do vagrant up for second project, I get the error

A VirtualBox machine with the name 'ubuntu-xenial-16.04-cloudimg' already exists.

In Vagrant's documentation it's clearly written that

Boxes are globally stored for the current user. Each project uses a box as an initial image to clone from, and never modifies the actual base image. This means that if you have two projects both using the hashicorp/precise64 box we just added, adding files in one guest machine will have no effect on the other machine.

Why then do I get this error?

I have already checked out other similar questions, but I don't understand their solution of deleting existing VMs that appear to have the same name. According to the Vagrant documentation quote above, that shouldn't be necessary. Am I missing something?

Luteous answered 11/5, 2016 at 14:34 Comment(2)
I'm getting a feeling that this has to do with how the box ubuntu/xenial64 was created. I repeated the same experiment with another box gbarbieru/xenial and that one has no such problem while creating multiple VMs. When I see VirtualBox GUI, I see that the VM name is automatically renamed to containing folder's name upon boot.Luteous
Is there any way to specify the name without editing the box directly? I prefer to use the default upstream settings and let vagrant abstract all of that away... That and I'd rather be able to bring up my box right after a git checkout instead of having to checkout then edit the box's VagrantFileUnderfur
B
20

You dont need to delete the other VM and indeed you can certainly have many VMs from the same box.

your error might have to do with the VirtualBox Name of the VM created in VirtualBox, If you have override a property to set this name and its the same name on your 2 projects then there will be a collision, see this answer to see the different ways to define the name of the VM

so either leave vagrant define the name of the VM or make sure you have unique VM name in your different project and it will run just fine

UPDATE I check this particular box and it contains the following Vagrantfile

Vagrant.configure("2") do |config|
  config.vm.base_mac = "02101FC67BA9"
  config.ssh.username = "ubuntu"
  config.ssh.password = "c1580f876b655137c6c35b69"
  config.vm.synced_folder '.', '/vagrant', disabled: true

  config.vm.provider "virtualbox" do |vb|
     vb.name = "ubuntu-xenial-16.04-cloudimg"
     vb.customize [ "modifyvm", :id, "--uart1", "0x3F8", "4" ]
     vb.customize [ "modifyvm", :id, "--uartmode1", "file", File.join(Dir.pwd, "%s-console.log" % vb.name) ]
  end
end

so make sure in your Vagrantfile to override this property

  config.vm.provider "virtualbox" do |vb|
     vb.name = "your specific project name"

and change the vb.name to be unique for each of your projects.

Beckybecloud answered 11/5, 2016 at 14:46 Comment(5)
noob question: how did you manage to view the Vagrantfile of ubuntu/xenial64?Luteous
its in ~/.vagrant.d/boxes/ubuntu-VAGRANTSLASH-xenial64/20160509.0.0/virtualbox/VagrantfileBeckybecloud
Thanks - I simply deleted the hardcoded vb.name from the box's Vagrantfile and am able to spin up multiple vagrant instances as normal now.Verrucose
This (plus Virtualbox Guest Additions installation) will be solved in the next version of the box: bugs.launchpad.net/cloud-images/+bug/1565985Ermey
I don't know but xenial box caused me lots of trouble. Very slow startup , errors during sudo apt-get .. and stupid default configuration.Quilting
C
2

I found that it is simpler to edit the original box's Vagrantfile (located ~/.vagrant.d/boxes/ubuntu-VAGRANTSLASH-xenial64/<VERSTION>/virtualbox/Vagrant‌​file) rather than thinking about unique VM names each time.

Working config of Vagrantfile (box!):

include_vagrantfile = File.expand_path("../include/_Vagrantfile", __FILE__)
load include_vagrantfile if File.exist?(include_vagrantfile)

Vagrant.configure("2") do |config|
  config.vm.base_mac = "0223C61ABA59"
  config.ssh.username = "ubuntu"
  config.ssh.password = "86f7d0e04910475d8789aa8f"
  config.vm.synced_folder '.', '/vagrant', disabled: true

  config.vm.provider "virtualbox" do |vb|
     vb.customize [ "modifyvm", :id, "--uart1", "0x3F8", "4" ]
  end
end
Centrifuge answered 22/7, 2016 at 9:55 Comment(0)
M
0

In my case I had only one project using this box. I tried to run vagrant destroy -f, which cleaned vagrant global-status, but when I ran:

ps aux |grep -i vbox

I see the box still running (it's on a CI executor node):

jenkins  1644999  7.0  0.1 4088636 60492 ?       Sl   mar21 4044:02 /usr/lib/virtualbox/VBoxHeadless --comment ubuntu-xenial-16.04-cloudimg --startvm b2ca853e-5593-4269-97cc-ae2aec269af8 --vrde config

Killing the box is not sufficient either.

Based on https://mcmap.net/q/173800/-a-virtualbox-machine-with-the-name-39-homestead-39-already-exists the solution that worked as a one-liner was:

    VBoxManage list vms |grep ubuntu-xenial-16.04-cloudimg |cut -d "{" -f2 |cut -d "}" -f1 |xargs -i VBoxManage unregistervm {} --delete
Marenmarena answered 30/4, 2023 at 7:59 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.