Packaging causes invalid paths + missing NAT. [Windows 7, VirtualBox 4.3.18]

[mookman288]

Environment

• vagrant.d and VirtualBox default locations have been moved to a partition specified for VM use (V:)
• Basic Debian box has been packaged within subfolders (V:\Vagrant\boxes\Deb) and is contained entirely within said directory
• NAT is set to port forward 22 => 2222, 80 => 8888, 443 => 4433 (the last two stripped by Vagrant)

Creation

1. vagrant package --base Deb
2. vagrant box add Deb
3. vagrant init Deb
4. vagrant up

Errors/Issues
The first error that is encountered is as such:

ERROR vagrant: Vagrant experienced an error! Details:
ERROR vagrant: #<Vagrant::Errors::VMBootBadState: The guest machine entered an i
nvalid state while waiting for it
to boot. Valid states are 'starting, running'. The machine is in the
'poweroff' state. Please verify everything is configured
properly and try again.

The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'starting, running'. The machine is in the
'poweroff' state. Please verify everything is configured
properly and try again.

Which leads me to the following issues:

#2157
#2187

Here, we find that it could be any number of things causing this issue, but the consensus is obviously to try it in the GUI. Which leads me to:

00:00:00.267371 VMSetError: C:\tinderbox\win-4.3\src\VBox\VMM\VMMR3\VM.cpp(365) int __cdecl VMR3Create(unsigned int,const struct VMM2USERMETHODS *,void (__cdecl *)(struct UVM *,void *,int,const char *,unsigned int,const char *,const char *,char *),void *,int (__cdecl *)(struct UVM *,struct VM *,void *),void *,struct VM **,struct UVM **); rc=VERR_PATH_NOT_FOUND
00:00:00.267375 VMSetError: Path not found.
00:00:00.267749 ERROR [COM]: aRC=E_FAIL (0x80004005) aIID={8ab7c520-2442-4b66-8d74-4ff1e195d2b6} aComponent={Console} aText={Path not found. (VERR_PATH_NOT_FOUND)}, preserve=false
00:00:00.292971 Power up failed (vrc=VERR_PATH_NOT_FOUND, rc=E_FAIL (0X80004005))
00:00:00.373249 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={480b372c-c0b5-4c23-9bd7-dcbb85b1594c} aComponent={Display} aText={The console is not powered up}, preserve=false
00:00:00.566468 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={480b372c-c0b5-4c23-9bd7-dcbb85b1594c} aComponent={Display} aText={The console is not powered up}, preserve=false

VERR_PATH_NOT_FOUND - indicating that having VirtualBox/Vagrant in this directory is probably causing some pathing issues. Okay, checking settings:

Now isn't that interesting? The location of the disk is:

V:\Deb_default_1413816308626_93374

Yet, it's looking for V:\Deb_1_1413816275606_40978\box-disk2.vmdk.

What's also interesting is there's a SECOND disk here:

V:\boxes\Deb\0\virtualbox\box-disk2.vmdk

OK, so I manually replace the vmdk within the GUI... and try again:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...

Looks like NAT isn't working now.

V:\Vagrant\boxes\Deb>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: VirtualBox VM is already running.

The machine is now running (we've avoided the shutoff problem) but NAT is busted.

It looks to me like a bug with pathing and packaging, but I could be very off base. Any suggestions or solutions?

[mitchellh]

I can't reproduce this. To "package" Vagrant almost quite literally calls VBoxManage exportvm with very few flags. I have a feeling that the issue is likely the environment is not normal. I'll have to work harder to try to repro this.

[mookman288]

Hi Mitchell,

Hmm. I'm on a brand new reinstall of Windows 7 x64 Professional, so I'll try to detail what steps I took to produce this.

• Installed Vagrant from Web (1.6.5)
• Installed VirtualBox from Web (4.3.18)
• Changed the Vagrant home variable to V:\ (VAGRANT_HOME)
• Changed the VirtualBox Default Folder to V:\ (File => Preferences => General)
• Added VBoxManage to the global PATH variable

Like I said earlier, the paths that are being output for the virtual machine after vagrant packages are what are really fascinating (not that I can get Vagrant to work as is.)

If you need me to provide any other information, I'd be more than happy to!

[MattLud]

I'm also able to produce this - I created a box via packer. I was having errors with corruption of the image so I uninstalled/reinstalled vagrant and restarted when asked.

When running

    vagrant up

I can see the box folder created and unpacking happening with the original box file. Very briefly the virtual box shows the original vm and renames it to _default_xxxxxxxxxxxxx - which my vagrantfile does not specify.

The machine fails to boot and I go into virtual box and try to fix the disk. I get an error that the disk UUID is already used associated with another vmdk.

Running a sthduuid on the default vmdk and then associating the VM with it allows the machine to properly boot and run through winrm and hostname renaming - the VM does not get renamed in virtual box though.

Here's the chained init and up log output - https://gist.github.com/Seakip18/e28e595e2f659126f397

[mitchellh]

After looking at the issues I'm going to close this as VirtualBox config issues. Their path configurations are notoriously annoying and cause issues like this. I haven't heard this from anyone else in about a year.

[leikotu]

I'm seeing this again on VirtualBox 5.0.16 r105871 and vagrant 1.8.1.

During box import, it is created on a temporary name (like centos6_1459956912300_18756), and subsequently renamed by vagrant when import is done. However, for some reason, the path to disk image (box-disk1.vmdk) is stored as an absolute path in created .vbox file, and is not correctly changed when the folder is renamed.

Yes, this might possibly be a virtualbox bug. A workaround would be nice. I tried to adopt a storageattach trick from http://stackoverflow.com/questions/21050496/vagrant-virtualbox-second-disk-path but my ruby-fu is not up to the task, me and colleagues being on windows and everything. I would only need to reflect the real path to the file, to this guy here:

v.customize ["modifyvm", :id, "storageattach","--storagectl","SATA", "--port","0","--medium",disk]

the only workaround i know of includes hand-modifying the .vbox file.

#3584 also might relate. What would be the correct place to report "virtualbox config issues"?

edit: if anyone wants to look at this.. i wasn't clear that a relative path in the .vbox file would work very well. it's just that modifyvm doesn't want to have one.