After learning for a couple of days I am happy to have successfully set-up my VM and run the Laravel start page. Very happy there :)
Can someone clarify "when" to use the vagrant functions. My questions:
If I'm planning to turn off my computer should you use halt or suspend? (I am guessing halt) What if I forgot to do any of these two, would it be a problem?
Right after I just turn on my computer should I use up or resume?
What if I am putting my computer to sleep mode by shutting the lid down, is it necessary to vagrant suspend?
In short
1. Shutting down
The "shutdown" methods differ in speed when you turn off/on the VM and in the amount of disk space the VM will take. From faster/more disk consumption to slower/less disk consumption, the comands are: vagrant suspend, vagrant halt and vagrant destroy.
2. Turning on
Just use vagrant up. The difference between the "startup" methods is that vagrant resume will just "wake up" the VM while vagrant up will make some config checks before this. For example, it will check if your vagrant box has a newer version and will notify you that you can update, by running vagrant box update.
Also you can use vagrant resume only on a VM that was previously suspended. Timewise, there is no noticeable difference between the two when used on a suspended machine.
For more details see the documentation references below.
3. Sleep/hibernation
Putting your computer to sleep or even hibernating it should cause no harm. The former is just a low power state while the latter saves the RAM to the storage drives and then restores it when you start your computer. This is OS level stuff, unless sleep failure or other problems occur it shouldn't influence anything.
Referencing the documentation
The Vagrant documentation has a section for what the different commands do:
Suspending the virtual machine by calling vagrant suspend will save the current running state of the machine and stop it. When you're ready to begin working again, just run vagrant up, and it will be resumed from where you left off. The main benefit of this method is that it is super fast, usually taking only 5 to 10 seconds to stop and start your work. The downside is that the virtual machine still eats up your disk space, and requires even more disk space to store all the state of the virtual machine RAM on disk.
Halting the virtual machine by calling vagrant halt will gracefully shut down the guest operating system and power down the guest machine. You can use vagrant up when you're ready to boot it again. The benefit of this method is that it will cleanly shut down your machine, preserving the contents of disk, and allowing it to be cleanly started again. The downside is that it'll take some extra time to start from a cold boot, and the guest machine still consumes disk space.
Destroying the virtual machine by calling vagrant destroy will remove all traces of the guest machine from your system. It'll stop the guest machine, power it down, and remove all of the guest hard disks. Again, when you're ready to work again, just issue a vagrant up. The benefit of this is that no cruft is left on your machine. The disk space and RAM consumed by the guest machine is reclaimed and your host machine is left clean. The downside is that vagrant up to get working again will take some extra time since it has to reimport the
Also regarding vagrant up and vagrant resume:
Command: vagrant up
This command creates and configures guest machines according to your Vagrantfile.
This is the single most important command in Vagrant, since it is how any Vagrant machine is created. Anyone using Vagrant must use this command on a day-to-day basis
Command: vagrant resume
This resumes a Vagrant managed machine that was previously suspended, perhaps with the suspend command.
Or just look at how the output of the two command differ in your terminal:
$ vagrant resume
==> default: Resuming suspended VM...
==> default: Booting VM...
...
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'laravel/homestead' is up to date...
==> default: Resuming suspended VM...
==> default: Booting VM...
...
During vagrant up you can see the the check in acton. If for example there is a newer version of your box, you will get a notification:
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'laravel/homestead' is up to date...
==> default: A newer version of the box 'laravel/homestead' is available! You currently
==> default: have version '0.3.3'. The latest is version '0.5.0'. Run
==> default: `vagrant box update` to update.
==> default: Resuming suspended VM...
==> default: Booting VM...
I usually use halt when I shut down my computer. When you suspend, I believe it stores the current stage image on disk. If you don't care about storage problem then you could use suspend.
If you suspended your VM then you should use resume so that last state is restored. If you just starting the VM, use "up"
I don't think it's necessary to suspend VM whenever when you hibernate your computer.
in short, if you use
$ vagrant suspend
then use
$ vagrant resume
but if you use
$ vagrant halt
then use
$ vagrant up
Related
I have pored through pages of Stack Overflow and find tons of answers that do not solve my inability to get "vagrant up" successfully...well, up on my Mac. Here is what happens:
ldco2016#DCortes-MBP-3 ~ $ vagrant init hashicorp/precise32 [ruby-2.3.0]
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
ldco2016#DCortes-MBP-3 ~ $ vagrant up [ruby-2.3.0]
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'hashicorp/precise32' is up to date...
==> 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 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
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.
Vagrant works properly on Mac OS X. The problem you described does seem to be a bug in Vagrant, nor your mistake.
Vagrant does not really perform complicated tasks related to virtual machines itself, but sets the options and runs other programs.
In this case Vagrant ordered VirtualBox to create and start a new virtual machine and then periodically checked that machine's status to connect when it got into a "running" state. Instead Vagrant was informed that the machine had been powered off:
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.
This indicates a problem with your VirtualBox (installation, settings, resources) and you should look there.
First run the Oracle VM VirtualBox Manager, right-click on the machine entry and choose "Show log..."; check if you can start the machine yourself; check the memory and CPU settings in VirtualBox.
Side note: Sometimes a tweak in Vagrantfile for OS X is required (mainly for disk sharing between the guest and host), but this is not the case with hashicorp/precise32. Using the two commands you ran, the machine started properly on El Capitan, Vagrant 1.8.4, VirtualBox 5.0.16.
hashicorp/* are pretty old boxes (generally older than 2 years).
You would want to use ubuntu/precise32 in your case, which are the official boxed maintained by folks from hashicorp
I destroyed my CoreOS vagrant box, then tried to re-up but it's hanging at:
==> core-01: Matching MAC address for NAT networking...
==> core-01: Checking if box 'coreos-alpha' is up to date...
==> core-01: Setting the name of the VM: coreos-vagrant_core-01_1447605695441_10076
In my VirtualBox graphical user interface, coreos-vagrant_core-01_1447605695441_10076 is shown as being Powered Off.
And then, nothing happens.
My question is: how best to debug this? How can I get more information about what is going on and where it's hanging?
vagrant up --debug will give you logging info from the VM
I had the same problem on Windows.
The suggestion (solution) based on my experience:
If you have updated/modified your puphpet config.yaml file recently:
If recenlty downloaded from puphpet.com make sure you have compatible vagrant version, currently: Minimum required Vagrant version is 1.7.4
Try changing your sync_type: to default (recommended for win is SMB, but for me personally this would cause to hang, until changed to default)
And last but not least, try running (up) with debug option, like so:
vagrant up --debug
P.S. Notice the double -- dash
When I run vagrant up it goes ok, but after Booting VM... step it stops with error:
==> default: Waiting for machine to boot. This may take a few minutes...
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.
I can run my image manually with VirtualBox GUI, it loads ok and shows me login:.
Is there any way to find what is wrong and how to fix it?
Here are more details:
CPU w/o virtualization
Vagrant 1.7.4
VirtualBox 5.0.8r103449
ruby 2.1.5p273 (2014-11-13 revision 48405) [i386-mingw32]
OS Name: Microsoft Windows 8.1 Pro
OS Version: 6.3.9600 N/A Build 9600
System Type: x64-based PC
Try running vagrant up --debug to help you debug.
For vagrant to boot up your virtual machine, it will have to ssh into it. If it cannot, it won't be able to carry out the command. This only happen when you create a complete new box. In case, it works in the past (meaning you already "vagrant up" before), and decides to be a jerk this time, then you may have to check the content of vagrantfile to see any misconfig.
I am setting up a Ubuntu 15.04 VM on Win7 using Vagrant 1.7.4 and VBox 5.0.0.
On the first vagrant up I can ssh into the machine using vagrant putty and everything is setup correctly and works. When I run vagrant halt, the VM shuts down gracefully without error messages.
However, when I try to restart the VM using vagrant up; vagrant putty, the machine is in a strange state. For example, the default synced folder /vagrant is empty, even though the second vagrant up call prints this message:
default: /vagrant => C:/Users/ArneUser/numecs/dev_env
Also, this vagrant up call prints the following message in PowerShell:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
/sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=
Stdout from the command:
Stderr from the command:
stdin: is not a tty
bash: line 2: /sbin/initctl: No such file or directory
I am running a really basic setup just to test for this error, so I don't think the mistake is in my provisioning script. Some pointers in the right direction would be appreciated.
Open VirtualBox GUI and turn off machine manually, then run again the vagrant up command.
That solved the problem in my case :)
/vagrant is empty
/sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=
From these two lines I suspect that MOUNTPOINT should be /vagrant but its due to /vagrant being empty that SSH is now working.
I've seen similar issues because of Virtualbox 5.
Try to downgrade Virtualbox to 4.3.x and ensure you have the latest Vagrant (1.7.4).
https://github.com/mitchellh/vagrant/issues/5572
Initctl is part of the Upstart init daemon. As far as I'm aware Ubuntu 15.04 is the first version of Ubuntu to abandon Upstart in favor of SystemD, so /sbin/initctl isn't expected to exist in your operating system. I believe this would need to be something that is fixed in the box you're using.
The point of "/sbin/initctl emit ..." is to notify other Upstart units that the vagrant shared folder has been mounted and is available for read/write operations. Since upstart is no longer in use it may be safe to assume that there is no need for this call. It's a rather crude hack, but you could make an empty script at /sbin/initctl. This should allow the vagrant startup process to continue properly and provision your box.
In my case it seems as Marc Young suggested that by opening Virtualbox GUI, the virtual machine itself seems to be hung. I saw these error messages on the virtual box console:
Thus it seems to not to be Vagrant related problem, but the virtual machine (Linux Kernel) itself seems to be hung.
I am on a Mac OS X Mavericks trying to run a Vagrant Windows 7 box (http://aka.ms/vagrant-win7-ie11).
Also I have installed the vagrant-windows plugin and have configured the Vagrantfile with the following properties:
PS: Don't consider the syntax below. It's just to represent what is configured in my file.
gui = true
memory = 2048
cpu = 2
So when I run the 'vagrant up' command I get this output:
gyo-macbook:Win7 gyo$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'win7'...
it takes forever and I don't see any progress nor any changes in the VirtualBox related vm folder.
Is there any steps I have forgotten?
Thank you,
Gyo
Vagrant downloads the box the first time you vagrant up. After downloading it unpacks the box and imports it into VirtualBox. Windows boxes are fairly large 5+ GB, so expect the first vagrant up to take time to complete.
If you open the VirtualBox GUI while vagrant is doing it's thing, you will see when the box gets added to VirtualBox. You can also see if the box is booting up in the little preview window in VirtualBox.