I am using VirtualBox 4.2.18 and Vagrant 1.3.3 on Window 7. I have done a vagrant box add
vagrant box add MyBox http://ergonlogic.com/files/boxes/debian-LAMP-current.box
But, when I get to the step of vagrant up I get the following error: "vboxmanage.exe error could not rename the directory..."
Any help would be appreciated.
Thanks,
Derek
I tried:
vagrant destroy -f
manually deleting the virtualboxes in their directory
restarting my machine
reinstalling both vagrant and virtualbox
downgrading vagrant and virtualbox
running with sudo
and nothing worked. The only thing that worked for me was opening Virtualbox interface and going to Preferences and changing the Default Machine Folder from VirtualBox VMs to just VMs
Wasted about 4 hours of my time on that problem. Hopefully someone with the same problem finds this post.
I went to the Directory
VirtualBox VMs
And deleted everything inside. Then I just did vagrant up, and it worked.
I was finally able to figure this out. Turns out it is useful to know how to set two specific directory paths for VirtualBox. This was particularly useful because I run my machine under an account that does not have administrative privileges. So I needed to get VirtualBox to used directory paths which I had access to security-wise. The first is the VBOX_USER_HOME environment variable which can be done within the System Properties/Environment Variables on Windows 7. In this way the VBOX_USER_HOME variable will control where the .VirtualBox directory goes. Secondly, set where the *.vbox files goes which is typically a directory called VirtualBox VMs. To set this path open the VirtualBox GUI and go to File Preference and set the path at the Default Machine Folder input box.
Hopefully this info will help others.
Derek
Thing that worked for me:
1) I had to manually delete C:\Users\My_name\VirtualBox VMs\machine_name folder.
2) To prevent this from happening again, before 'vagrant destroy' command I always stop current machine with 'vagrant suspend'.
I just removed every sub folder under this folder and it worked
Don't destroy your vagrant machine! This is a last option.
Write in you console:
VBoxManage list vms
Copy id of your machine, something like:
7fca07b2-65c6-420e-84b5-b958c15449a1
Open your vagrant machine id file, something like:
.vagrant/machines/default/virtualbox/id
Replace with id you just copied and do:
Vagrant up
This allways works for me. If not, only as last option you can try: vagrant destroy -f
On Windows 10 using VirtualBox v6.1.26 I encountered the same problem.
Here is how I could re-create the VM after a broken vagrant destroy
Try:
Run vagrant destroy -f
Check the available machines with vagrant global-status --prune
Find the VMs folder in C:/Users/your_username/.VirtualBoxMachines and try deleting the one with the name of your machine using the file explorer manually
If you cannot delete the folder (some processes has open files with in it), try restarting your computer and delete then
Now it should work again with vagrnat up
This worked for me!
That error means there is other VM in Virtual Machine with the same name as the one you used for this VM. So go back to the folder of that VM you run previously and destroy it with "vagrant destroy -f". Then try again running this VM.
Vagrant
Working with Vagrant I had a similar error. This was due to naming conflicts. What solved it for me was to remove the name of the instance from the Vagrantfile.
vb.customize ["modifyvm", :id,
"--name", "oracle",
"--memory", "512",
"--natdnshostresolver1", "on"]
Change that to
vb.customize ["modifyvm", :id,
"--memory", "512",
"--natdnshostresolver1", "on"]
You Just need find your folder called VirtualBox VMs
In that folder should see your machines
And rename what folder you want, and run:
vagrant up
So you have run it successfully.
vagrant destroy -f
find the folder VirtualBox VMs --> delete the machine you want to
rename
Run vagrant up in your project root
This worked for me!
i don't know how it works but i just kill the process of VB like the Following image and i run 'vagrant reload'
In windows OS, if none of these solution works, try to run the command in PowerShell as Administrator.
Gentleman and ladies oh no. Just go to the vagrant file change the file
vb.customize ["modifyvm", :id,
"--name", "oracle",
"--memory", "512",
"--natdnshostresolver1", "on"]
change the name variable as it conflicts with another 'installed' or failed to 'installed' vagrantbox. the new Vagrantfile should be like:
vb.customize ["modifyvm", :id,
"--name", "oracle2",
"--memory", "512",
"--natdnshostresolver1", "on"]
On Ubuntu 20.04
First, run
vagrant destroy
Go to this directory
/home/your_username/VirtualBox VMs
This step deletes all your VMs:
Delete all files and directories in that directory like so
rm -rf *
And then run
vagrant up
Related
I'm working on a number of projects on cloud9 IDE, and it's really frustrating that I can't get the better errors gem to work correctly. It isn't supposed to need initializing; it should just work out of the box. However, I still only get the usual ugly red errors page. I should specify that it is included in my gemfile, and I have bundle install already.
How can I get better errors to work correctly? Is there an installation step I'm missing?
The trick, I used, to get the 'better_errors' gem working in Cloud9 is setting the value of TRUSTED_IP to the public IP address of the computer my browser session is attached to. (As far as I can tell, it has nothing to do with the IP address of the remote server or Cloud9 server addresses.)
I'll outline the process I used to get 'better_errors' working on my Cloud9 workspace, from my Chromebook on my residential network... maybe it will also work for you and others!
Add gem "better_errors" to the development group in the project Gemfile.
Add gem "binding_of_caller" to the project Gemfile.
Run $bundle in the project Cloud9 terminal.
Edit the project config/environments/development.rb file and add the following line of code to the end of the Rails.application.configure block.
BetterErrors::Middleware.allow_ip! ENV['TRUSTED_IP'] if ENV['TRUSTED_IP']
Create a new "runner" in Cloud9 by clicking "Run" > "Run With" > "New Runner".
Cloud9 creates an basic runner file in a new tab to modify. Replace the contents of this file with following code.
{
"cmd": [
"bash",
"--login",
"-c",
"TRUSTED_IP=XXX.XXX.XXX.XXX rails server -p $port -b $ip $args"
],
"working_dir": "$project_path",
"info": "Your code is running at \\033[01;34m$url\\033[00m.\n\\033[01;31m",
"selector": "source.ru"
}
Replace XXX.XXX.XXX.XXX in the code above with the local computer's public IP address. (I use http://ifconfig.me/ to find the public IP assigned to my Chromebook.)
Save the runner file with the name RoR.run into the /.c9/runners path for the project.
Start the projects server by using this new runner. Click Run > Run With > RoR.
Use the popup link that Cloud9 displays, after the runner starts the server, to view the app. Enjoy 'better_errors'!
NOTE: I still have not figured out how to automate the process of feeding the external IP address of my local computer into the RoR.run file that lives on the Cloud9 workspace. I just update it manually every time I move to a new network or my external IP address changes.
WARNING: I actually just started learning RoR, so I have no idea if this is the "correct" way to get this gem to work in a cloud dev server/service environment. I also have no idea how safe this would be. I suspect that my solution exposes the 'better_errors' in-browser REPL to all computers that resolve to that same external IP address. If you are working on a sensitive codebase/database please do not implement my solution.
I just tested this in cloud9.io and this is the simplest way to make this work in cloud9.io:
Add the following line to config/environments/development.rb:
BetterErrors::Middleware.allow_ip! 'xxx.xxx.xxx.0/24'
where xxx.xxx.xxx is the first three sections of the IP address of the local machine that you are using to connect to cloud9.io
There is a good answer in the better errors issues and c0 docs.
Issues:
https://github.com/charliesome/better_errors/issues/318
c9 Help
https://community.c9.io/t/white-listing-remote-addr-for-better-errors-gem/4976/4
Use a Rack::Request object to get the IP. You can put the following code in your view.
if Rails.env.development?
request = Rack::Request.new(env)
puts "###### Request IP_ADDRESS = #{request.ip}"
end
Change the last quadrant of the IP you get to 0/24. For example.
BetterErrors::Middleware.allow_ip! '76.168.69.0/24' <--note: change the last quad to 0/24 and of course your ip address will be different than 76.168.69.xx
Yeah!! I got it! Automatically!
Here is my solution:
1- Similar as described by #Grokcodile: edit the project config/environments/development.rb file and add the following line of code to the Rails.application.configure block.
BetterErrors::Middleware.allow_ip! ENV['TRUSTED_IP'] if ENV['TRUSTED_IP']
config.web_console.whitelisted_ips = ENV['TRUSTED_IP']
2- At the Cloud9 edit the ~/.bashrc...
vi ~/.bashrc
add the line (enter, alt+a):
export TRUSTED_IP='0.0.0.0/0.0.0.0'
Save it (esc, :wq)
3- run rails s -b $IP -p $PORT as usual...
4- Enjoy better errors!!
If you also work on this project at a Virtual Machine(vagrant):
1- edit at your VM (vagrant) your ~/.bash_profile (my case) and add:
export TRUSTED_IP=x.x.x.x
export PORT=3000
export IP=0.0.0.0
x.x.x.x must be equal to the REMOTE_ADDR of ENV. (This in not a problem like cloud9 because at my VM the IP doesn't change everytime: 10.0.2.2 always for me).
With this I am now able to use the gem foreman: foreman start at both places with the Procfile:
web: rails s -b $IP -p $PORT
This works because the global env variables are set on both.
I am just starting to learn RoR too, so, hope this is the right thing to do without bringing more problems in the future.
Because Cloud9 is all web-based you don't access it from localhost so by default better errors won't work. If you take a look at the security section of their README (https://github.com/charliesome/better_errors) you can add the following to config/environments/development.rb:
BetterErrors::Middleware.allow_ip! <ipaddress>
So that the errors page shows for your IP. You can find your apparent IP by hitting the old error page's "Show env dump" and looking at "REMOTE_ADDR".
How should I use the command vagrant destroy?
In my VagrantFile I used vm.config.name = 'websvr' and when I open Virtualbox I can see websvr on the list of Vm's.
But whenever I use vagrant destroy websvr it returns:
The machine with the name 'websvr' was not found configured for this Vagrant environment.
How does vagrant destroy work?
It seems the item does not exist, but it appears in the list because it is present in the cache. Use vagrant global-status --prune to get rid of it.
See vagrant global-status documentation for more details.
Lets try these action in command line
Check available installed boxes by calling
vagrant box list
Find box id
vagrant global-status --prune
Select by id name of your box for destroying.
vagrant destroy 1a2b3c4d
Thats all for you. Now you can destroy your vagrant box vagrant destroy xxxxxxx by this command.
Try running vagrant status first, which should list all of your VMs with their current status (running, not created, etc.)
The names of the VMs are displayed in the first column and are case sensitive.
For example, this is what the output of vagrant status looks like on my machine:
base not created (virtualbox)
git not created (virtualbox)
go not created (virtualbox)
dev_workstation not created (virtualbox)
single_instance not created (virtualbox)
metrics not created (virtualbox)
To completely clean VM and start from fresh - the below worked for me - basically combination of what others have said already.
Check VM status with vagrant locally and destroy if exists - all done inside vagrant folder - MAKE SURE you are in the correct folder!
$ vagrant status
$ vagrant destroy
$ rm -rf .vagrant
Check VM status with vagrant globally and "destroy" if exists - can be done from anywhere
$ vagrant global-status
$ vagrant global-status --prune
Check VM status with VirtualBox's perspective and unregister VM
$ vboxmanage list vms
### note down long id, eg. c43266e6-e22b-437a-8cc1-541b7ed5c4b
$ vboxmanage unregistervm <long id> --delete
Go back into appropriate vagrant folder and start VM
$ vagrant up
To destroy the vagrant you may try these simple steps:
You need to exit the ssh if you are already running vagrant ssh command you can type in exit to come out of vagrant ssh.
Once you are out of vagrant type:
vagrant destroy -f.
If these don't work out for you you may try it using bash.
Jump into the project folder where your actual code resides. Right-click and press git bash here. You will see a bash window popping up so just type in the same command in bash window: vagrant destroy -f.
I hope these simple steps work out for you.
I'm trying to create multiple-boxes to be loaded by vagrant when writing
vagrant up kali
vagrant up metasploitable2
The Config I have set-up are
Within the Kali VagrantFile
Vagrant.configure("1") do |config|
config.vm.define "kali" do |kali|
kali.vm.box = "Kali"
end
end
Within the Metasploitable2
Vagrant.configure("1") do |config|
config.vm.define "metasploitable2" do |metasploitable2|
metasploitable2.vm.box = "metasploitable2"
end
end
If I browse to the directory where the .vmdk and Vagrantfile are located and say
vagrant up kali
it creates the kali image, however if i'm not in the directory it won't load the VM.
with an error:
The machine with the name 'kali' was not found configured for
this Vagrant environment.
I'm going to presume this is because it's not being able to read the configuration file, but how can i make this globally because I thought you weren't supposed to modify the 'global' vagrantfile at all.
Well, Vagrant has to find the Vagrantfile to read it, doesn't it? =)
So you either have to be in the same directory or any subdirectory below it. Or you can set VAGRANT_CWD environment variable to point to the directory. See the "Lookup Path" section in the Vagrantfile documentation for more information.
You can of course make wrapper script or other shortcuts if you need to use that often.
Btw, you might want to upgrade your Vagrantfiles to use V2 configuration format to use all new features of Vagrant 1.1+.
I need to do some customization on created VM either before importing it or just before running it first time. For instance, I need to clear stale NAT port forwarding rules that tend to be left after the box with the same name, remove some disk controllers (reattach existing disks to IDE controller instead of SATA for compatiblity with older OS revisions that do not understand SATA, etc).
There are pre-boot and pre-import events in Vagrant code, but I wonder if there's any way of running some virtualbox/vagrant commands before booting created vm?
Yes, for running VBoxManage commands, see the "VBoxManage Customizations" chapter in the docs. The commands are by default run on pre-boot phase, but you can also specify the phase as a first argument:
Vagrant.configure("2") do |config|
# ...
config.vm.provider "virtualbox" do |v|
v.customize "pre-boot", ["modifyvm", :id, "--cpus", 2]
end
end
But I think there problem is that you don't have an easy and reliable way to get the disk image path.
Somehow my Vagrant project has disassociated itself from its VirtualBox VM, so that when I vagrant up Vagrant will import the base-box and create a new virtual machine.
Is there a way to re-associate the Vagrant project with the existing VM?
How does Vagrant internally associate a Vagrantfile with a VirtualBox VM directory?
For Vagrant 1.6.3 do the following:
1) In the directory where your Vagrantfile is located, run the command
VBoxManage list vms
You will have something like this:
"virtualMachine" {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
2) Go to the following path:
cd .vagrant/machines/default/virtualbox
3) Create a file called id with the ID of your VM xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
4) Save the file and run vagrant up
WARNING: The solution below works for Vagrant 1.0.x but not Vagrant 1.1+.
Vagrant uses the ".vagrant" file in the same directory as your "Vagrantfile" to track the UUID of your VM. This file will not exist if a VM does not exist. The format of the file is JSON. It looks like this if a single VM exists:
{
"active":{
"default":"02f8b71c-75c6-4f33-a161-0f46a0665ab6"
}
}
default is the name of the default virtual machine (if you're not using multi-VM setups).
If your VM has somehow become disassociated, what you can do is do VBoxManage list vms which will list every VM that VirtualBox knows about by its name and UUID. Then manually create a .vagrant file in the same directory as your Vagrantfile and fill in the contents properly.
Run vagrant status to ensure that Vagrant picked up the proper changes.
Note: This is not officially supported by Vagrant and Vagrant may change the format of .vagrant at any time. But this is valid as of Vagrant 0.9.7 and will be valid for Vagrant 1.0.
The solution with upper version is quite the same.
But first you need to launch the .vbox file by hand so that it appear in VBoxManage list vms
Then you can check the .vagrant/machines/default/virtualbox/id to check that the uuid is the right one.
Had the issue today, my .vagrant folder was missing and found that there was a few more steps than simply setting the id:
Set the id:
VBoxManage list vms
Find the id and set in {project-folder}/.vagrant/machines/default/virtualbox/id.
Note that default may be different if set in your Vagrantfile e.g. config.vm.define "someothername".
Stop the machine from provisioning:
Create a file named action_provision in the same dir as the id file, set it's contents to: 1.5:{id} replacing {id} with the id found in step 1.
Setup a new public/private key:
Vagrant uses a private key stored in .vagrant/machines/default/virtualbox/private_key to ssh into the machine. You'll need to generate a new one.
ssh-keygen -t rsa
name it private_key.
vagrant ssh then copy the private_key.pub into /home/vagrant/.ssh/authorized_keys.
Update with same problem today with Vagrant 1.7.4:
useful thread at https://github.com/mitchellh/vagrant/issues/1755
and specially with following commands:
For example, to pair box 'vip-quickstart_default_1431365185830_12124' to vagrant.
$ VBoxManage list
"vip-quickstart_default_1431365185830_12124" {50feafd3-74cd-40b5-a170-3c976348de27}
$ echo -n "50feafd3-74cd-40b5-a170-3c976348de27" > .vagrant/machines/default/virtualbox/id
For multi-VM setups, it would look like this:
{
"active":{
"web":"a1fc9ae4-5d43-49cb-be31-ab3c4f74745d",
"db":"13503bc5-76b8-4c26-95c4-32435b372212"
}
}
You can get the vm names from the Vagrantfile used to create those VMs. Look for this line:
config.vm.define :web do |web_config|
"web" is the name of the vm in this case.
This is modified from #Petecoop's answer.
Run vagrant halt if you haven't shut down the box yet.
Then list your virtualboxes: VBoxManage list vms
It'll list all of your virtualboxes. Identify the box you want to revert to and grab the id between the curly brackets: {}.
Then edit the project id file: sudo nano .vagrant/machines/default/virtualbox/id (from the project directory)
Replace it with the id you copied from the list of VBs.
Try vagrant reload.
If that doesn't work and gets hung on SSH authorization (where I stumbled), copy the insecure public key from the vagrant git. Replace the content of /.vagrant/machines/default/virtualbox/private_key. Backup the original of course: cp private_key private_key-bak.
Then run vagrant reload. It'll say it's identified the insecure key and create a new one.
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
You should be all set.
I'm using Vagrant 1.8.1 on OSX El Capitan
My vm was not shut correctly when my computer restarted, so when i tried vagrant up it was always creating new vm. No solutions here worked for me. But what did work was a variation of ingmmurillo's answer
So instead of creating .vagrant/machines/default/virtualbox/id based on the id from running VBoxManage list vms. I had to update the id in .vagrant/machines/local/virtual_box/id
I've got a one liner that essentially does this for me:
echo -n `VBoxManage list vms | head -n 1 | awk '{print substr($2, 2, length($2)-2)}'` > .vagrant/machines/local/virtualbox/id
This assumes the first box is the one i need to start from running VBoxManage list vms
In Vagrant 1.9.1:
I had a VM in Virtual Box named 'Ubuntu 16.04.1' so I packaged it as a vagrant box with:
vagrant package --base "Ubuntu 16.04.1"
responds with...
==> Ubuntu 16.04.1: Exporting VM...
==> Ubuntu 16.04.1: Compressing package to: blah blah/package.box
I'm on macos and found that removing the .locks on the boxes solved my problem.
For some reason
vagrant halt
did not remove these locks, and after restoring all my settings in .vagrant/machine/default/virtualbox using timemachine, removing the locks, the right machine booted up.
Only 1 minor problem remains, It booted into grub so I had to press enter once, don't know if this is staying, but I will find out soon enough.
I'm running vagrant 1.7.4 and virtualbox 5.0.2
for me deleting the
cd yourVagrantProject/.vagrant/machines/default/virtualbox/
rm id
worked.