This seems to be common problem:
Lets say i have a project which has Vagrantfile. So i executed "vagrant up" and vagrant machine is up and running. So for so good.
After few days i synced the same project codebase to another location on same machine and tried to execute vagrant up. But this time it failed saying "vagrant cant forward request to this port 8080". This is because another vagrant instance occupied this port 8080.
Now if i want to know from where this vagrant box spin off, how can i do this?
This command will tell you the state of all Vagrant environments:
$ vagrant global-status
If you would stop any machin, you can use:
$ vagrant halt id
Related
First, apologies: I'm a newbie.
I've created a very basic Vagrantfile by running Vagrant init. I only made a few changes:
config.vm.box = "generic/fedora28"
config.vm.box_version = "1.8.32"
config.vm.provider "libvirt" do |lv|
lv.memory = "4096"
end
(There are also a few items in my config.vm.provision section).
After running vagrant up , the process gets stuck at
==> default: Waiting for domain to get an IP address...
I'm running this off a Fedora 27 box, which uses version 2.0.2 of the Vagrant package (even though current is 2.1.5).
I've tried adding this line:
config.vm.network "private_network", ip: "192.168.100.101"
but it had no effect.
Can anyone help?
I have a Vagrant File that spins up 4 VMs, of image generic/ubuntu2004 on libvirt kvm, to make a k3s cluster that's accessible on the LAN. (multipass + k3s is only accessible via localhost b/c it doesn't allow easy bridging.)
I ran both of these commands > 50 times
sudo vagrant destroy --force --parallel
sudo vagrant up
On the ~51'st time, I noticed vagrant up got stuck on "Waiting for domain to get an IP address..."
What fixed it for me was sudo reboot. You know the classic have you tried unplugging it and plugging it back in?
Something else to try (I rebooted before trying it)
https://bugzilla.redhat.com/show_bug.cgi?id=1283989
I have a custom vagrant box based on the offcial box ubuntu 16.04.
I simplly run like this to get the packaged box.
vagrant init ubuntu/xenial64; vagrant up --provider virtualbox
vagrant up
vagrant ssh # enter the virtual machine and do some custom change on it
vagrant halt
vagrant package --vagrantfile Vagrantfile --output custom_ubuntu1604.box
and then i copy the file custom_ubuntu1604.box to another directory, i use the box like this:
vagrant box add ubuntu1604base custom_ubuntu1604.box
vagrant init ubuntu1604base
vagrant up # at this point the machine will be stopped at "Started Journal Servie"
my new virtualbox machine base on the new packaged box will stop at:
the screenshot
And finally it timed out:
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within the
configured ("config.vm.boot_timeout" value) time period.
If you look above, you should be able to see the error(s) that Vagrant
had when attempting to connect to the machine. These errors are
usually good hints as to what may be wrong.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes. Verify
that authentication configurations are also setup properly, as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
Try to set config.vm.boot_timeout in Vagrantfile more than default e.x.600. From my experience I found out it take a long time at the first time to connecting guest machine.
For example
Vagrant.configure("2") do |config|
config.vm.box = "ubuntu/xenial64"
config.vm.provider "virtualbox"
config.vm.boot_timeout = 600
end
I tried to setup a new Laravel project this afternoon and I must have did something to my Homestead/Vagrant configuration that ruined it. I think the command I used was vagrant reload {id}.
Now when I try to start my machine, I get the following error:
Bringing machine 'homestead-7' up with 'vmware_fusion' provider...
==> homestead-7: Checking if box 'laravel/homestead' is up to date...
==> homestead-7: Verifying vmnet devices are healthy...
==> homestead-7: Preparing network adapters...
Vagrant found a port collision for the specified port and virtual machine.
While this port was marked to be auto-corrected, the ports in the
auto-correction range are all also used.
VM: homestead-7
Forwarded port: 80 => 8000
When I run Vagrant global-status, I get this:
id name provider state directory
-----------------------------------------------------------------------
410757f homestead-7 vmware_fusion not running /Users/Me/Homestead
I can't run vagrant reload 410757f as I get the same error above, and I can't provision the machine because it needs to be running.
I'm confused as to whats happening here. There is a networking colission, but I don't have any other vagrant boxes. I currently have 4 other Windows VM's, but I made sure I shut down each machine.
I've even tried destroying and recreating the homestead box (no luck). Any ideas?
Edit To extend on this, I tried looking for the process using sudo lsof -i :8000
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
vmnet-nat 3943 root 42u IPv4 0x70d4a03b6f2dddd 0t0 TCP *:irdmi (LISTEN)
I killed that using sudo kill -9 3943 and ran sudo lsof -i :8000 again, which gave me nothing, then running homestead up again gave me the same error.
I seemed to solve this by removing and reinstalling VMWare.
Based on my readings online, the issue seemed to be with a cached setting relating to a previous VM on Fusion. Rather than hunt down what that might have been, I thought it was easier to just delete everything and reinstall.
I followed the instructions here and then downloaded and reinstalled it from the VMWare website.
I hope this helps someone in the future!
After vagrant halt and vagrant destroy and after a cd && cd .vagrant/boxes && rm -rf ... I've been continuing to see a box.
I've also pruned vagrant cache with command vagrant global-status --prune.
Here the output of vagrant status:
Current machine states:
my-vagrant-api not created (virtualbox)
What I need to do to totally remove Vagrant box from an Host?
Nothing you have to do. It is already deleted.
It is only showing vagrant machine configuration that you defined in Vagrantfile. See the output:
my-vagrant-api not created (virtualbox)
It is saying vagrant machine with name my-vagrant-api is defined in Vagrantfile but not created.
If it is created then it will look like:
vagrant status
Current machine states:
server1 poweroff (virtualbox)
server2 poweroff (virtualbox)
server3 running (virtualbox)
This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run `vagrant status NAME`.
If you don't want this configuration then you can simply delete that Vagrantfile
I installed a vagrant virtual machine in Windows, it's working fine, I am trying to connect to the guest machine from windows, but as soon as I uncomment some thing in Vagrantfile like :
config.vm.network "private_network", ip: "192.168.33.10"
OR
config.vm.network "public_network"
when reloading vagrant, I got this error :
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.
If the provider you're using has a GUI that comes with it,
it is often helpful to open that and watch the machine, since the
GUI often has more helpful error messages than Vagrant can retrieve.
For example, if you're using VirtualBox, run `vagrant up` while the
VirtualBox GUI is open.
The primary issue for this error is that the provider you're using
is not properly configured. This is very rarely a Vagrant issue.
I know this does not make sense but I just open VirtualBox and with right-click goes to Settings of created vagrant machine image and diable Audio and it is working after save and run vagrant up
I never encountered that error personally, having never used vagrant on windows. This issue has been discussed here.