hashicorp/vagrant · error · Vagrant::Errors.VirtualBoxNameExists

The name of your virtual machine couldn't be set because Vir

Error message

The name of your virtual machine couldn't be set because VirtualBox
is reporting another VM with that name already exists. Most of the
time, this is because of an error with VirtualBox not cleaning up
properly. To fix this, verify that no VMs with that name do exist
(by opening the VirtualBox GUI). If they don't, then look at the
folder in the error message from VirtualBox below and remove it
if there isn't any information you need in there.

VirtualBox error:

%{stderr}

What it means

After import, Vagrant renames the VM with `VBoxManage modifyvm <uuid> --name <name>`. If VBoxManage fails and its stderr contains VERR_ALREADY_EXISTS, the driver re-raises it as VirtualBoxNameExists. It means VirtualBox already has a VM (or a leftover on-disk machine folder) registered under that name, typically residue from an unclean destroy.

Source

Thrown at plugins/providers/virtualbox/driver/version_5_0.rb:782

        def remove_dhcp_server(network_name)
          execute("dhcpserver", "remove", "--netname", network_name, retryable: true)
        end

        def set_mac_address(mac)
          mac = "auto" if !mac
          execute("modifyvm", @uuid, "--macaddress1", mac, retryable: true)
        end

        def set_name(name)
          retryable(on: Vagrant::Errors::VBoxManageError, tries: 3, sleep: 1) do
            begin
              execute("modifyvm", @uuid, "--name", name)
            rescue Vagrant::Errors::VBoxManageError => e
              raise if !e.extra_data[:stderr].include?("VERR_ALREADY_EXISTS")

              # We got VERR_ALREADY_EXISTS. This means that we're renaming to
              # a VM name that already exists. Raise a custom error.
              raise Vagrant::Errors::VirtualBoxNameExists,
                    stderr: e.extra_data[:stderr]
            end
          end
        end

        def share_folders(folders)
          is_solaris = begin
                         "SunOS" == read_guest_property("/VirtualBox/GuestInfo/OS/Product")
                       rescue
                         false
                       end
          folders.each do |folder|
            # NOTE: Guest additions on Solaris guests do not properly handle
            # UNC style paths so prevent conversion (See GH-7264)
            if is_solaris
              hostpath = folder[:hostpath]
            else
              hostpath = Vagrant::Util::Platform.windows_path(folder[:hostpath])

View on GitHub (pinned to 35f3160f4a)

Solutions

Open the VirtualBox GUI and remove any VM with that name (check File > Tools > Virtual Media Manager too)
If no VM is registered, delete the leftover machine folder named in the VBoxManage stderr shown in the error
Run `vagrant global-status --prune` and destroy stale entries pointing at the same box
Retry `vagrant up` once the name collision is cleared

Defensive patterns

Strategy: validation

Validate before calling

existing = `VBoxManage list vms`.scan(/^"(.+?)"/).flatten
raise 'name collision' if existing.include?(target_vm_name)

Type guard

def vm_name_free?(name)
  !`VBoxManage list vms`.scan(/^"(.+?)"/).flatten.include?(name)
end

Prevention

After a failed `vagrant destroy`, verify with `VBoxManage list vms` that the VM is really gone
Periodically prune stale machines: `vagrant global-status --prune`
Avoid reusing fixed VM names when importing boxes manually

When it happens

Trigger: set_name(name) inside a retryable block catches Vagrant::Errors::VBoxManageError whose extra_data[:stderr] includes 'VERR_ALREADY_EXISTS' — triggered when a VM with the target name is still registered, or the machine folder `<VirtualBox VMs>/<name>/` still exists from a previous run.

Common situations: A previous `vagrant destroy` failed halfway (VBoxManage locked, host crashed); duplicate machines from parallel `vagrant up` runs; a stale machine directory left in the VirtualBox VMs folder; manually imported/copied VMs sharing the name.

Related errors

AI-assisted analysis of hashicorp/vagrant@35f3160f4a (2026-08-21). Data as JSON: /api/errors/4d3836ad3c96c776. Report an issue: GitHub.