Tag Archives: homestead

Fixing Vagrant VMs after a VirtualBox upgrade

Leave a reply

I use virtual machines to split up my web development projects. This lets me have a small Linux server run inside my Mac, allowing me to match the operating system with what the code will run in on a public service, without going all the way to running Linux all the time. As I want an easy life when it comes to setting these up, I use Vagrant to make and manage the virtual machines within VirtualBox, which runs them for me.

Recently I set up an extra Vagrant virtual machine (VM) to hold two projects for a client and keep them separate from some of my own projects, as they needed particular settings within Linux and a different database server to run them than the settings and database for my own projects.

I used a Homestead VM, as I knew the settings were good. Homestead is made for Laravel PHP sites, but is perfectly valid for lots of other PHP projects. My client uses various versions of the Symfony framework, and they work fine within Homestead built boxes.

The new VM worked fine but the existing VM stopped working. I could start it, I could SSH into it, but I couldn’t get any websites from it to show in the browser. Which is a big problem, as that’s all it is there for.

After much faff and investigation, I discovered the problem is a bug in the current version of VirtualBox. I had updated it while setting up the new VM, but unlike previous upgrades, this caused a problem. VirtualBox needs VMs to use IP addresses within the 192.168.56.0/21 range or the “bridge” between MacOS and the virtual machine doesn’t work, so no web pages show.

The IP of the old Homestead box my own projects were in was 192.168.10.10, which was the default when I installed it. That used to work, but now does not. The new VM uses 192.168.56.4, which is within the allowed range, so it worked fine.

To fix the old VM:

I had to edit the Homestead.yaml file. At the top where it says:

ip: "192.168.10.10"

I changed it to:

ip: "192.168.56.10"

I then ran:

vagrant reload --provision

To get vagrant to reconfigure the existing Homestead box to use this changed IP address, without deleting anything inside the VM.

And finally I edited the entries in my hosts file (which is in /etc for me in MacOS) for the websites in the VM, changing their IP from 192.168.10.10 to 192.168.56.10

Once all that was done, the websites in the VM started working again.

This was a very, very frustrating problem. I spent a long time investigating what was happening inside the VM as I presumed that’s where the problem was, eventually stumbling on the solution after searching for wider and wider versions of the problem. Thanks to Tom Westrick whose post on Github got me to the solution.

Getting MySQL data out of a Homestead virtual machine when Vagrant is broken

Leave a reply

I’ve now learned how to get data out of a Vagrant run virtual machine when Vagrant itself is broken. Steps below.

I recently upgraded my Mac to use Mojave and this broke my old Vagrant install, which I use for Homestead and a bunch of my Laravel based development websites. It was a bit of an old version of Vagrant, but still annoying. At first I thought VirtualBox, the software for creating virtual machines, just needed updating. Unfortunately an upgrade of VirtualBox was required for it to run in Mojave, but not the solution to my problem.

In general, the virtual machine (VM) breaking wasn’t a problem – I have all the site files as part of the point of using Vagrant is having those in a shared folder on your main file system, not only inside the VM Vagrant sets up to hold the development environment. So I’d lost the development environment, including Apache, MySQL, and some other bits, but not the files of my site and the environment would be easy to set up again as that’s what Vagrant makes simple.

But… I had a bunch of data in two databases within MySQL in the VM that I really wanted to keep. Upgrading Vagrant would mean wiping the data, so I didn’t want to do that. I thought to recover the data and back it up I was going to have to restore a Time Machine backup of the whole computer back to the previous version of the OS – High Sierra.

Fortunately I mentioned the problem to a few friends (AKA I moaned about my situation) and Tom  suggested I mount the VM direct. That inspired me to start poking around more, here is how I got my data out of the broken Vagrant box…

Recovery steps

Open VirtualBox and manually start the machine Vagrant set up by clicking on it and clicking the start icon.

This boots the virtual machine and gives me a command prompt.

At “homestead login:” I needed a username and password, the default for a Vagrant built VM is vagrant and vagrant (thanks to Stefan on Stackoverflow for putting up that one.)

Then I needed to backup my databases on the command line. I’m used to using web based tools for MySQL admin, so had to look this up too:

mysqldump -u homestead -psecret --all-databases > homestead-20190121.sql

Thanks to Jacob for that one.

This gives me a big text file with all the exported data in it, which is great, but the file is still inside the virtual machine, not on my normal file system where I can get at it.

After much thought I remembered what Tom had advised me in the first place – mount the VM as a drive. I took that as the starting point of some Googling and set up a shared folder using this advice.

That involved re-starting the VM and then once I was logged in, I needed to check what that shared folder was called from within the Ubuntu VM and with more searching based on some very old memories from university, I found this command:

df -h

Which lists the share to a folder called “2019 01 January” which I’d set up. It was under /media/sf_2019_01_January

So within the VM I then did:

sudo cp homestead-20190121.sql /media/sf_2019_01_January/

Because the first time I ran it, I didn’t have enough permissions to copy the file. Sudo let me temporarily have more permissions and do the copy.

Checking in the shared folder, I found all my data. I can now use this to restore the databases elsewhere.

To cleanly close down the VM, I used:

shutdown

This has a delay built in, so I now know I should have used:

poweroff

Which would have been a bit quicker.