Please read the update at the bottom of this post before making any conclusions. I wanted to leave the rest of the post unedited, but needed to update my current situation as it has changed since this post was written…
From my previous posts on VirtualBox 7.0.x you will know I’ve been having problems with it. They all seem to come down to networking. I can often, but not always, start up an existing VM, but if I try to build a new VM with Vagrant it will fail to setup the networking. Also, if I attempt to use Packer, it will fail to find the kickstart file, which it attempts to access over HTTPS. Both cases seem to be network related.
I’ve done all the usual firewall and antivirus stuff, and trawled the internet to see if anyone else has a solution. None of that has helped.
When I saw VirtualBox 7.0.4 I was hoping this might solve my problem, but no. I get the same issues on Windows 11, Windows 10 and macOS (Intel). This makes VirtualBox 7.0.4 unusable for me.
When I revert back to VirtualBox 6.1.40, everything works as expected…
I don’t know if this is just me, or if a lot of people are having problems with VirtualBox. It seems odd that I am getting the same result on multiple machines on two fundamentally different architectures though.
So my current suggestion would be use this at your own risk…
Vagrant 2.3.3 has also been born. Upgrading to this didn’t cause or solve any issues for me. Even though I’ve had to revert back to VirtualBox 6.1.40, this new version of Vagrant is working fine for me.
At some point since my last run of Packer builds version 1.8.4 was released. This follows the same pattern. It works great with VirtualBox 6.1.40, but doesn’t work at all with VirtualBOx 7.0.x.
Sadly VirtualBox 7.0.x is still a bust for me. Maybe I’m the only one on the planet, but it is unusable for me. I hope this changes in the future as I rely on VirtualBox bigtime…
Update: I’ve now switched to using VirtualBox 7.0.4 completely, and all issues have been resolved. This post by Frits Hoogland explained what my problem was. This is solved by adding the “–nat-localhostreachable1” parameter. That solved my Packer problem, and subsequent VM problems. Happy days…
Update 2: An update from Simon Coter suggests the issue is due to the way Vagrant and Packer use the VirtualBox CLI, rather than the API. The workaround mentioned in the previous update is still the easiest way to move forward.
Main: Fixed issue when VBoxSVC could become unresponsive if Extension Pack was not installed (bug #21167)
I’ve installed 7.0.2 on a couple of Windows machines (10 and 11), and I’m going to play with it today.
As mentioned in my post about VirtualBox 7.0, Vagrant 2.3.1 doesn’t support VirtualBox 7.0 directly, so I was expecting a quick release of Vagrant and here it is. Vagrant 2.3.2 has a single feature in its changelog.
provider/virtualbox: Add support for VirtualBox 7.0 [GH-12947]
I’ll be attempting some new Packer builds of my Vagrant boxes, then working through my Vagrant and Docker builds to add in the new patches. That should give it a pretty good test. I’ll update this post with the results.
If this doesn’t work out, I’ll be reverting to VirtualBox 6.1.40…
Update 1: The good news is VMs seem to start OK now using Vagrant 2.3.2 and VirtualBox 7.0.2. (not true, see below)
The bad news is I can’t get Packer to work, so I’m unable to build new Vagrant boxes with the 7.0.2 guest additions. I’ve tried on Windows 10, Windows 11 and macOS (Intel) and all result in the same issue. It seems the kickstart is not working, like the networking on VirtualBox 7.0.2 is screwed up somewhere.
I’ve downgraded my Windows 10 PC to use VirtualBox 6.1.40 and I’m building new Vagrant boxes on that. So far so good. I’ll upload them to Vagrant Cloud and attempt to use them with VirtualBox 7.0.2. The guest additions will be out of date, but it should still work fine, I hope. I’ll keep updating…
Update 2: After a couple of successes starting up VMs using VirtualBox 7.0.2 and Vagrant 2.3.2, it all seems to have caved in now.
I’m going to switch to VirtualBox 6.1.40 for the moment. I don’t have more time to waste on this. VirtualBox and Vagrant are tools I use to make my life easier, not an end in themselves, so I don’t have the time to keep working on this. I’m sure a future version of VirtualBox will have sorted out its networking issues and I’ll be able to use it…
Update 3: Everything is reverted to VirtualBox 6.1.40. Packer builds of OL7, OL8 and OL9 are completed and uploaded to Vagrant Cloud. I’ve started to do some Vagrant builds with them now and they seem to be working fine, so what I’m seeing is on VirtualBox 6.1.40 everything works as usual. On VirtualBox 7.0.2 I see these two issues.
Packer just doesn’t work. It fails getting the HTTP access to the kickstart file. I get the same issue on Windows 10, Windows 11 and macOS (Intel).
Starting VirtualBox VMs with Vagrant is hit-or-miss. Sometimes they work, but sometimes they fail. It also seems network related, but I can’t be 100% about that.
Update 4: An update from Simon Coter suggests the issue is due to the way Vagrant and Packer use the VirtualBox CLI, rather than the API. The workaround for this was posted by Frits Hoogland here.
VirtualBox installed with no drama (see update below) on my Windows hosts. Something a little funky happened on macOS (Intel), so I removed VirtualBox and installed it again. It worked fine the second time.
The current version of Vagrant (2.3.1) fails with a version compatibility error when used with VirtualBox 7. Fortunately Simon Coter has our back, and previously published this workaround. I’m sure a new version of Vagrant will come soon, making this workaround unnecessary.
I’ll be doing new Packer builds of my Vagrant boxes over the next few days. If they are delayed, it means I’m having some drama with the new version of VirtualBox. 🙂
Update: So things aren’t looking so great. Even with the Vagrant workaround there seems to be a few issues. Sometimes Vagrant just hangs. No apparent reason why. Sometimes VirtualBox networking just doesn’t work. Vagrant can’t create the network. At this point I’m not sure if the issues are with Virtual or just a problem with VirtualBox. At one point I got a very similar issue when using VirtualBox directly (no Vagrant). It is happening to me on both Windows 10 and Windows 11, so it seems pretty consistently bad. Let’s see if there are any quick updates to VirtualBox or Vagrant in the next few days, but for now I would avoid VirtualBox 7 until the issue is a little clearer.
Update 2: VirtualBox 6.1.40 has been released. It may be safer to use that rather than version 7 at the moment…
Update 3: An update from Simon Coter suggests the issue is due to the way Vagrant and Packer use the VirtualBox CLI, rather than the API. The workaround for this was posted by Frits Hoogland here.
The quarterly Oracle security patches trigger a whole bunch of build changes for me. This post just gives you a run through of what happened over the weekend.
The release of VirtualBox 6.1.36 means all my Vagrant boxes on Vagrant Cloud have the wrong guest additions, so I rebuilt all of them using Packer. The Oracle Linux 7, 8 and 9 boxes are now up to date. You can see my Packer builds under my Vagrant repository on GitHub here.
Note. During the packer builds I noticed the VirtualBox 6.1.36 guest additions require some extra packages during the installation (libX11, libXt, libXext, libXmu).
I had recently updated all relevant Vagrant builds with the latest versions of Tomcat, SQLcl and ORDS updates, but I was still waiting on the OpenJDK 11.0.16 release. On Friday morning I noticed Adoptium released it, so I made the necessary changes to the builds to include it. I usually don’t include Oracle patches in my database builds, but some installations, like Oracle 19c on OL8, require them. I’ve updated them to include the 19.16 patches where necessary. You can find my Vagrant builds on GitHub here.
Similar to the Vagrant section above, the relevant Docker/Podman builds were updated to use OpenJDK 11.0.16, and the Oracle 19c on OL8 build had it’s patch script modified for the 19.16 patches. You can find my container stuff on GitHub here.