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

Vagrant was unable to determine the recommended name for you

Error message

Vagrant was unable to determine the recommended name for your
VirtualBox VM. This is usually an issue with VirtualBox. The output
from VirtualBox is shown below, which may contain an error to fix.
The best way to fix this issue is usually to uninstall VirtualBox,
restart your computer, then reinstall VirtualBox.

VirtualBox output:

%{output}

What it means

Identical logic to the 5.x driver, but in the VirtualBox 6.x driver: `vagrant up` dry-runs `VBoxManage import -n <ovf>` and matches `Suggested VM name "..."` to derive a collision-free VM name. When the regex fails to match VBoxManage's output, VirtualBoxNoName is raised with the raw output attached. It points at a VirtualBox-side failure (install, version, or box OVF), not at Vagrant configuration.

Source

Thrown at plugins/providers/virtualbox/driver/version_6_0.rb:29

        def initialize(uuid)
          super

          @logger = Log4r::Logger.new("vagrant::provider::virtualbox_6_0")
        end

        def import(ovf)
          ovf = Vagrant::Util::Platform.windows_path(ovf)

          output = ""
          total = ""
          last  = 0

          # Dry-run the import to get the suggested name and path
          @logger.debug("Doing dry-run import to determine parallel-safe name...")
          output = execute("import", "-n", ovf)
          result = /Suggested VM name "(.+?)"/.match(output)
          if !result
            raise Vagrant::Errors::VirtualBoxNoName, output: output
          end
          suggested_name = result[1].to_s

          # Append millisecond plus a random to the path in case we're
          # importing the same box elsewhere.
          specified_name = "#{suggested_name}_#{(Time.now.to_f * 1000.0).to_i}_#{rand(100000)}"
          @logger.debug("-- Parallel safe name: #{specified_name}")

          # Build the specified name param list
          name_params = [
            "--vsys", "0",
            "--vmname", specified_name,
          ]

          # Target path for disks is no longer a full path. Extract the path for the
          # settings file to determine the base directory which we can then use to
          # build the disk paths
          result = /Suggested VM settings file name "(?<settings_path>.+?)"/.match(output)

View on GitHub (pinned to 35f3160f4a)

Solutions

  1. Inspect the 'VirtualBox output:' block in the message for the concrete VBoxManage error
  2. Run `VBoxManage import -n <extracted box .ovf>` by hand to reproduce and see the failure
  3. Free disk space / fix permissions on the VirtualBox VMs directory if import reports write errors
  4. Re-download the box (`vagrant box remove` then `vagrant up`)
  5. Uninstall VirtualBox, reboot, reinstall the current 6.x release
Defensive patterns

Strategy: validation

Validate before calling

out = `VBoxManage import -n /path/to/box/box.ovf 2>&1`
abort 'VirtualBox import dry-run broken - reinstall VirtualBox' unless out.match?(/Suggested VM name "/)

Prevention

When it happens

Trigger: First `vagrant up` of a box under VirtualBox 6.x where `execute("import", "-n", ovf)` output contains an error or omits the 'Suggested VM name' line — e.g. broken VBoxManage, unreadable/corrupt .ovf, or an import blocked by disk space/permissions before the name is suggested.

Common situations: VirtualBox 6.x installation damaged by an OS upgrade or partial uninstall; box archive corrupted during download; host disk full so the import dry-run fails early; mixing old VBoxManage 5.x binaries on PATH with a 6.x install.

Related errors


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