Vagrant: Guest machine default name too long with VirtualBox 5.2.8 (VERR_CFGM_NOT_ENOUGH_SPACE)

[gael-ian]

Hello,

After upgrading to VirtualBox 5.2.8 today, some of my Vagrant-managed virtual machines simply refused to boot, with the VBoxManage start-vm command returning this error:

There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "af3e1b26-bc41-407e-847f-2f520ca237e6", "--type", "headless"]

Stderr: VBoxManage: error: The specified string / bytes buffer was to small. Specify a larger one and retry. (VERR_CFGM_NOT_ENOUGH_SPACE)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole

After some research, I found the problem was the default name build by Vagrant for the impacted virtual machines was too long. Internal buffer size for this name may have been shortened in VirtualBox 5.2.8, as everything worked fine before upgrade.

It's an easy problem to fix, as you only need to manually set the name of your VM, but maybe Vagrant can handle this in a better way, either with a more understandable error message or by building default names that will not exceed the limit.

For information, my impacted default machines names were 78 and 79 chars long.

Thanks

[ruzickap]

Thanks for sharing it... I got a same issue...

[cheeseplus]

What research led you to the name length issue?

I've attempted to reproduce this one by forcing names of 90+ characters with VirtualBox 5.2.8 and 5.2.10 and can't get the failure.

[gael-ian]

In my browser history, I can still find tracks to the VirtualBox OSE Changelog and some really old code excerpts but, reading it again today, I don't remembr how a name length error on module loading leads me to shorten my VM name.

Sorry, that was a while ago so I can't be more precise.

[cheeseplus]

No worries, this issue was opened on a related repo of mine and when I went to test 5.2.8 and 5.2.10 I couldn't force the error based on the length of the automatically generated name from:

https://github.com/hashicorp/vagrant/blob/c31f87d434eba736840ada97d88207ca663f43db/plugins/providers/virtualbox/action/set_name.rb#L23-L30

Or when setting that value manually. Mostly wanted to follow up here for the Vagrant folks as I am unable to reproduce and thinking the nature of the error might be slightly different than name length.

[ravn]

Issue present on 18.04 with Vagrant 2.0.4 (manually downloaded) and VirtualBox 5.2.10 (upgraded by Ubuntu).

There was an error while executing VBoxManage, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "906c75c8-74e8-4d4a-81ee-e864c8d2da6d", "--type", "headless"]

Stderr: VBoxManage: error: The specified string / bytes buffer was to small. Specify a larger one and retry. (VERR_CFGM_NOT_ENOUGH_SPACE)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole

Renaming directory holding vagrantfile from long name to three character name, made this work.

[briancain]

Hey everyone! I also just attempted to reproduce this, but could not based on the information in this thread. I tried both virtualbox 5.2.8 and 5.2.10 on macOS high sierra and ubuntu 16.04 with both a folder name and guest name above 150 characters. I'm guessing there is likely something missing beyond the name here that's triggering this error.

For whoever is running into this problem, please provide us with a full debug log from Vagrant, as well as your Vagrantfile. It might also be worth listing how much RAM your machine has? If you can reproduce the error with vboxmanage maybe you could run the startvm command with debug on too?

[ravn]

vagrant.log

Vagrantfile.zip

Machine has 32 GB RAM.
digital-pligtaflevering-aviser-tools_default_1525247039605_35180-2018-05-02-10-04-36.log

Exact instructions on how to get the information needed would have been nice.

[chrisroberts]

@ravn That information is perfect, thanks!

[chrisroberts]

@ravn Could you try adding this to the virtualbox provider block in your Vagrantfile:

v.customize ["modifyvm", :id, "--audio", "none"]

ensure the guest is fully destroyed and then run a vagrant up and see if the error persists.

Thanks!

[kosch]

@chrisroberts adding v.customize ["modifyvm", :id, "--audio", "none"] fixed this problem for me, thanks. (ubuntu, vbox 5.2.12)

[chrisroberts]

@kosch Awesome, thanks for the confirmation! I had tracked it down to mostly likely being the cause in the vbox source, but wasn't able to reproduce it locally.

[cheeseplus]

Amazing find @chrisroberts - does this have any intersection with the virtualbox guest additions being (not-)installed?

Wondering if I can make the bento boxes safer by disabling that one in an embedded Vagrantfile and/or via kitchen-vagrant.

[chrisroberts]

@cheeseplus I'm not entirely sure. It can definitely be added in the embedded Vagrantfile to always disable audio, and users could override it locally if it's something that they want. It looks to be an issue with vbox itself, though I haven't dug hard enough to find the original cause for the change in behavior. It has to do with the allocated size for the variable to hold the path internally, which is not long enough for the actual path (which results in the some what misleading error message).

[ravn]

Sorry, I missed this in my inbox.

This change allows my VM to boot, thank you.

I agree in the assumption that this is an internal VirtualBox string that
has been made smaller triggering this. Do the VirtualBox team know this is
a real problem to people?

Thanks again.

On Wed, May 2, 2018 at 4:10 PM, Chris Roberts [e-mail]
wrote:

@ravn https://github.com/ravn Could you try adding this to the
virtualbox provider block in your Vagrantfile:

v.customize ["modifyvm", :id, "--audio", "none"]

ensure the guest is fully destroyed and then run a vagrant up and see if
the error persists.

Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/vagrant/issues/9524#issuecomment-385990711,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHJMjYrS2O6_dlyTaeV-CMFzDiqzQoGks5tub5BgaJpZM4SWf0v
.

--
Thorbjørn Ravn Andersen - "...plus...Tubular Bells!"

[chrisroberts]

Closing this as an upstream issue.

@ravn I didn't find anything in the virtualbox bug tracker and have so far been unable to reproduce the issue locally to create a new issue with the required debug logs and the like.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.