Vagrant (or VirtualBox) creates .vmdk file on a different folder #3584

Closed
pablocrivella opened this Issue Apr 30, 2014 · 9 comments

Projects

None yet

7 participants

@pablocrivella

I am not sure if this is a bug of Vagrant or VirtualBox (or a bug at all).

I have this VagrantFile

VAGRANTFILE_API_VERSION = '2'

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box      = 'precise64'
  config.vm.box_url  = 'http://files.vagrantup.com/precise64.box'
  config.vm.hostname = 'rails-forge'

  # Port 3000 is required by Rails
  config.vm.network :forwarded_port, guest: 3000,  host: 3000
  # Port 35729 is required by LiveReload to reflect content changes
  config.vm.network :forwarded_port, guest: 35729, host: 35729

  # Directory structure for default host apps folder
  # workspace
  # --vagrant-enviroments
  # -----rails-apps-dev-box
  # --rails-apps
  # -----app-1
  # -----app-n
  config.vm.synced_folder config.user.host.apps_folder, '/home/vagrant/apps'

  config.vm.provision :shell, path: 'scripts/upgrade_puppet.sh'

  config.vm.provision :puppet do |puppet|
    puppet.manifests_path = 'puppet/manifests'
    puppet.module_path    = 'puppet/modules'
    puppet.options        = '--verbose --debug --hiera_config /vagrant/puppet/hiera.yaml'
  end

  config.vm.provider 'virtualbox' do |vb|
    vb.name = 'rails-forge'
  end
end

When i run vagrant up everything works just fine but the generated files look like this:

VirtualBox VM's Dir

-- Virtual Machines
----- precise64
---------- box-disk1.vmdk
----- rails-forge
---------- Logs
---------- rails-forge.vbox
---------- rails-forge.vbox.prev

But on a older version of vagrant (i don't know which one because i've updated vagrant several times since i created the vm) the generated files used to look like this:

VirtualBox VM's Dir (using an older Vagrant Version)

-- Virtual Machines
----- rails-forge
---------- Logs
---------- rails-forge.vmdk
---------- rails-forge.vbox
---------- rails-forge.vbox.prev

I work o a Windows 7 x64 Enviroment with Vagrant 1.5.4 and Virtualbox 4.3.8 r92456 installed.
Later i'm going to check this issue on a linux enviroment.

@mitchellh
Owner

This is VirtualBox.

@mitchellh mitchellh closed this Apr 30, 2014
@atti187
atti187 commented May 6, 2014

I have the same issue. Can it be solved by changing any settings in VirtualBox?

@deframe
deframe commented Jun 2, 2014

Exactly the same problem with a freshly installed Virtualbox 4.3.12 and Vagrant 1.6.3. What is going on here?

@keiths-osc
Contributor

@mitchellh I noticed this behavior as well. I did some digging and discovered that there actually is a bug in Vagrant that would only be noticed on Windows hosts.

The VirtualBox driver in Vagrant is specifically trying to make sure the virtual hard disks don't end up in a different folder. This method executes vboxmanage import -n to get the "suggested name" of the VM and the physical paths of the virtual disks for the box that is about to be imported, and then specifically tries to replace the disk paths that were spit out by the vboxmanage import -n with new paths that correspond to whatever new name the machine is going to get. The bug is on on this line. The path.sub contains forward slashes, but on windows, the paths spit out by the vboxmanage import -n contain backslashes.

The reason I came across this is because if you try to name your VM the same name that it originally had when you packaged up the box, then the vagrant up fails, and this issue appears to be related. For example, this Vagrantfile:

Vagrant.configure('2') do |config|   
  config.vm.define :testbox do |testbox|
    testbox.vm.box = 'opscode_centos-6.4_provisionerless'
    testbox.vm.box_url = 'https://opscode-vm.s3.amazonaws.com/vagrant/opscode_centos-6.4_provisionerless.box'        

    testbox.vm.provider :virtualbox do |vb|
      vb.name = 'centos-6.4'
    end 
  end
end

results in this error:

Bringing machine 'testbox' up with 'virtualbox' provider...
==> testbox: Importing base box 'opscode_centos-6.4_provisionerless'...
==> testbox: Matching MAC address for NAT networking...
==> testbox: Setting the name of the VM: centos-6.4
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["modifyvm", "8eab4aa6-ef15-4574-ada4-f0c398519671", "--name", "centos-6.4"]

Stderr: VBoxManage.exe: error: Could not rename the directory 'D:\VirtualBox\VMs\centos-6.4_1403640749742_63814' to 'D:\VirtualBox\VMs\centos-6.4' to save the settings file (VERR_ALREADY_EXISTS)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component SessionMachine, interface IMachine, callee IUnknown
VBoxManage.exe: error: Context: "SaveSettings()" at line 2716 of file VBoxManageModifyVM.cpp

(On my system, my VirtualBox Default Machine Folder happens to be D:\VirtualBox\VMs).

@keiths-osc
Contributor

One other piece of information related to my last post...

I went ahead and hacked my locally installed copy of the Vagrant gem so that this line contained backslashes instead of forward slashes in the sub. It did cause the vmdk to end up in the right spot. However, it did not take care of the second issue I mentioned where the vagrant up fails if you try to name your VM the same name that it originally had when you packaged up the box. I'll log a separate issue for that.

@keiths-osc
Contributor

Actually, I was right the first time! :) The line that's causing the vmdk to end up in the wrong folder is also responsible for the error I reported that occurs if you give the VM the same name that it originally had when you packaged up the box. The reason it still failed after I hacked my local copy of Vagrant is because there was an empty centos-6.4 subdirectory left over from my prior failed attempts to bring up the VM. (vagrant destroy removed the vmdk but left the centos-6.4 subdirectory). If I ensure that the centos-6.4 subdirectory does not exist, then I no longer get the error (after hacking the line I mentioned so that it contains backslashes instead of forward slashes).

@michaeljquinn

How is this closed - It too am having this issue in Windows 7 (64bit prof) host and Vagrant 1.6.3
VBoxManage works no problem, vagrant does not !!!
When is this being fixed

@sneal
Collaborator
sneal commented Jul 2, 2014

#4133 fixes this issue.

@michaeljquinn

All Good
this is not in the 1.6.3_2 release though
When does it get into Vagrant download ?

---- Shawn Neal notifications@github.com wrote:

#4133 fixes this issue.


Reply to this email directly or view it on GitHub:
#3584 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment