Imaging I am running a Virtual Machine guest (VM) managed by Vagrant and hosted by VirtualBox on Windows. What happens if the HOST is abruptly powered off? Is whatever data that has been added/updated to the VM lost? If this is the case, must I run vagrant halt to insure nothing is lost? Perhaps vagrant suspend would be sufficient?
Thank you for any insights or recommendations.
If the host crashes, the VirtualBox VMs will end to aborted state, but in many cases vagrant up should be enough to get them running again.
If you're unlucky and the VM got corrupted it might be that only destroying and creating it again helps. But that's why you make all modifications via provisioners, don't you? =)
vagrant halt or vagrant suspend won't do nothing in this case, as the VM is not running.
And if the host is just shut down normally, the running VMs should be suspended by recent VirtualBox versions.
If the host suffers from a power loss, the same happens to all the running guests as if they were suddenly powered off.
Data loss can happen, but it depends on the file system mount options, results can vary.
For Linux VMs using ext4 as its main file system, I'd recommend using data=journal instead of the default data=ordered and turn write barriers on by using barrier=1. The above can be done in /etc/fstab. This will help to minimize the possibility of data loss but it is NOT 100% guaranteed.
HTH
Related
I've installed virtio-win on the Windows guest.
Actually it works fine but one problem is that the service can not be automatically started, if do so, not memory stats can be found in the host.
When I manually started or restarted, the stats will works okay.
How could that happened? Is the problem of virtio-win or mine? I just installed it without any actions :(
Thank you for your help.
Using a new install of Laravel with Laravel Homestead I've been trying to get Vagrant to boot, but it keeps timing out. I tried using the Default virtual switch, as well as the DockerNAT and NewInternalVirtualSwitch which is a virtual switch I added using the Hyper-V Manager.
I know I can leave the provider as VirtualBox and turn off Hyper-V, but since we use Vagrant and Docker for different application doing this over the last couple days has become tedious since Docker for Windows on Windows 10 Pro requires Hyper-V to be on so each time you have to shut down and restart in either direction.
Has anyone gotten Laravel Homestead to work using the Hyper-V provider, and what steps did you have to take to get networking to work which appears to be the issue?
Homestead.yaml
ip: 192.168.10.10
memory: 2048
cpus: 1
provider: hyperv
authorize: ~/.ssh/example/id_rsa.pub
keys:
- ~/.ssh/example/id_rsa
folders:
-
map: 'D:\Projects\example\server'
to: /home/vagrant/server
sites:
-
map: server.app
to: /home/vagrant/server/public
databases:
- example
name: example
hostname: example
Vagrant Up
Bringing machine 'example' up with 'hyperv' provider...
==> example: Verifying Hyper-V is enabled...
==> example: Importing a Hyper-V instance
example: Please choose a switch to attach to your Hyper-V instance.
example: If none of these are appropriate, please open the Hyper-V manager
example: to create a new virtual switch.
example:
example: 1) DockerNAT
example: 2) Default Switch
example: 3) NewInternalVirtualSwitch
example:
example: What switch would you like to use? 3
example: Cloning virtual hard drive...
example: Creating and registering the VM...
example: Setting VM Integration Services
example: Successfully imported a VM with name: ubuntu-16.04-amd64_1
==> example: Starting the machine...
==> example: Waiting for the machine to report its IP address...
example: Timeout: 120 seconds
example: IP: fe80::215:5dff:fe38:107
==> example: Waiting for machine to boot. This may take a few minutes...
example: SSH address: fe80::215:5dff:fe38:107:22
example: SSH username: vagrant
example: SSH auth method: private key <--- Stalls out for a couple minutes
Error
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.
Update
Also tried tip 4 using an external virtual switch and it makes it further, but still fails with an error while trying to assign a hostname:
==> example: Machine booted and ready!
==> example: Setting hostname...
No host IP was given to the Vagrant core NFS helper. This is
an internal error that should be reported as a bug.
Edit: After setting it all up and testing workflow, I went back to VirtualBox + Homestead and disabled Hyper V. The bottom line is that Windows and Linux are not very compatible with each other and while Hyper V is native to Windows, everything that follows won't be and even simple tasks like copying files and setting permissions require a lot of labor.
I will leave my answer below, maybe someone else or I will come back to it in the future.
I just spent a day trying to get it to work and I couldn't but I came up with a solution that works better for me at least so I'll share it here.
If your workstation runs Windows 10 Pro with Hyper V and you know how to set up your production server, then it might work for you.
The idea is to give up on Homestead and set up your local server just like you do the production server but on Hyper V:
Enable Hyper V
Download your server OS image (Ubuntu 18.04 for me) and create a virtual machine with it.
Choose what you need from the list of software included in homestead and install those on the virtual machine (for me its Nginx, PHP, PostgreSQL, Git, Python, and Composer).
At this point you pretty much have your custom made Homestead on Hyper V. Log into the virtual machine, copy its ip (it should show it upon login but if not, here is a command to bring it up on Ubuntu ip addr show eth0 | grep inet | awk '{ print $2; }' | sed 's/\/.*$//'), enter it into the browser window and it should bring the default Nginx frontpage up.
It's pretty easy, but the problem is that this ip is dynamic and it will keep resetting. The toughest part is to make it static.
Set ip in the Hyper-V manager to static right click the virtual machine -> Settings -> Network Adapter -> Advanced Features. Reboot everything
Set ip to static in the OS in virtual machine (guide for Ubuntu 18.04). Note that ip address of the host Hyper V vEthernet adapter (ipconfig on Win 10 to bring it up) is the gateway address for the virtual machine OS.
So pros and cons from my perspective.
Pros:
Works faster and cleaner on Windows + Hyper V than on Windows + Oracle Virtual Box
Customizable and updatable. The only way to update Homestead seems to be delete it and download the new one.
Cons:
Hard to set up if you are not familiar with your production server setup
Setting up static IP is really a painful lot of hacking
Accessing files between Linux and Windows requires Samba dependency
Managing permissions of Linux files accessed through Windows is complicated
Linux guest doesn't seem to have access to GPU through Hyper V
This problem may happen because by default, the Hyper-V switches are treated as Public network; the Windows firewall blocks access to virtual machines.
One easy but dangerous workaround is to simply turn off the Windows firewall. You can do that to test whether this is your problem, but of course do not leave the firewall off.
A better solution is to disable the firewall only for the network switch (or switches). This cannot be done in the GUI; you need an elevated PowerShell for that.
set-NetFirewallProfile -DisabledInterfaceAliases NewInternalVirtualSwitch,DockerNAT,Default
Note that if you want to disable the firewall for multiple switches, you must specify all of them in a single call to Set-NetFirewallProfile.
An even better solution would be to change the switches to private network, but I am not aware of any way to do that.
Had similar issues here (on Windows 10 Home) trying to run Docker along side Homestead. I can't say for sure what did the trick but I ended up with this:
In Windows features turn on:
Virtual Machine Platform
Windows Hypervisor Platform
Windows Subsystem for Linux
Used HyperVSwitch to turn on even more Hyper-V (just turning it on as a "Windows feature" is not enough!) https://unclassified.software/en/apps/hypervswitch
Restart Windows
In the VirtualBox manager disabled "Adapter 2" for the Homestead machine (Settings > Network > Adapter 2 > uncheck Enable Network Adapter)
Run the Homestead machine as normally.
Adapter 2 will be turned on again once you restart the Homestead machine But it seams that it now works fine in combination with all the Hyper-V settings.
Since it was a lot of trail, error and restarting of servers I'm not sure what exactly did the trick but I hope it helps some people in their quest to run Docker and Homestead together.
I know now at least that it's possible :)
I am kind of new to using vagrant with oracle's virtual box. I was wondering if anyone knows if it is a good idea or not to use vagrant halt before restarting or rebooting my host machine?
Vagrant halt
is another way of saying shutdown; it is a good practice to do that since it will attempt to shut the VM gracefully where as windows will force it to. As a result you may sometimes get an error saying the VM wasn't shut properly and is now on a protected mode or saved mode and need to be rebuilt.
I am pretty new to vagrant. I have installed an ubuntu 14.04 trusty box on my vagrant and will use it for my web development environment. I want to know which is the best way to disable/close/shutdown a vagrant box so that data in it remain safe in the next session? I mean when I want to shutdown my laptop (in windows 10, my host machine os is win10) there is a message telling me that virtualbox interface is open. so if I close the process then I cant access vagrant box anymore. I want a good way to close vagrant and run it in my next working session.
I read about vagrant halt before host shutdown and using vagrant up in next session but it takes too long to run a vagrant up.
**summary : I WANT A WAY TO DO THIS:
1- close a vagrant box without a data loss in it;
2- shutdown my laptop without seeing the message that tells virtualbox interface is open.
3- run vagrant box and access it with putty as fast as possible when I start working again.
is there a way to do this?**
thanks.
I want to know which is the best way to disable/close/shutdown a vagrant box so that data in it remain safe in the next session
I would not necessarily to recommend vagrant halt which will completely stop your VM and will need to start up after you restart your host.
You can run vagrant suspend which will hold your data and you will retrieve your instance in the same state as it was before on your next startup
You can read more about the differences between halt and suspend
Hadoop & Vagrant: If I set up a new VM using these two packages, is the VM available for starting with VirtualBox or do I always have to use vagrant up?
When you first create the VM, you will need to use vagrant up since VirtualBox has no ability to read a Vagrantfile. Once your VM is up and running, you could stop and start it using VirtualBox. However, Vagrant can perform the same operations as VirtualBox and has a lot of advantages on top of that.
First let's discuss how Vagrant can do what VirtualBox can do. You can use vagrant suspend to put the VM in a saved state, vagrant resume to start it again, vagrant halt to power it off, and vagrant destroy to delete it. You can also use settings in Vagrant's VirtualBox provider to modify your VM's memory, CPUs, and more. You can also change the network settings and synced folders. And this gives you the advantage of defining all of these settings in code which can be checked into a revision control system such as Git.
On top of all this, Vagrant has support for provisioners. These range from something as simple as shell scripts to full blown configuration management tools such as Puppet, Chef, Ansible, and Salt. Just like you can define your VM's VirtualBox settings in code, you can define the entire creation process including installing packages, managing services, and customizing files. And you can make changes at any time and apply them using vagrant provision.
So getting back to your question... yes, you can control your VM directly with VirtualBox, but you'd be missing out on the rich feature set of Vagrant.