29
votes
Tildes dev environment on Apple Silicon // Apple M1
I'm having some trouble getting the local developer environment set up on Apple hardware, specifically it seems because Virtualbox, which is used as the provider, is not properly functioning on Apple hardware.
Is there anyone here who has managed to get it up and running?
With the default VM box
"debian/contrib-buster64"
and the apple m1 developer preview of virtualboxvagrant up
fails on startup withStderr: VBoxManage: error: The object is not ready VBoxManage: error: Details: code E_ACCESSDENIED (0x80070005), component SessionMachine, interface IMachine, callee nsISupports VBoxManage: error: Context: "GetCPUExecutionCap(&u32)" at line 1200 of file VBoxManageInfo.cpp
I did some digging and it seemes like the virtualbox developer preview does not function well, and has very limited compatibility with various linux distros https://forums.virtualbox.org/viewtopic.php?f=8&t=107344#p528167
It seems like at the minimum I would have to find another provider that would be compatible, but google does not provide much help with this.
you can use VMWare or Docker as a backend, but I'm not too sure on how you'd have to modify the Vagrantfile to achieve that
Had similar issues. For me the VirtualBox VM just kept locking up on “vagrant up” without much explanation.
Did you manage to get it working? Supposedly changing the provider to VMware could perhaps solve it? Though I don't know how compatible it is with Apple Silicone, or if that would break something else specific to the tildes environment.
No, I haven't solved it yet. I have had some success (not with Tildes) with VMs on HyperKit via Multipass on M1, but I don't think thats an option here.
I'll be watching this post to see if anyone else has any luck, and I'll update here too if I can figure anything out.
@Deimos, @Maxi, moving here from the other topic
I wrote this before I saw the update from @Maxi which confirms the same thing. Seems like there's no quick win here.
After some digging, I found this thread regarding M1/M2 support with VirtualBox.
...
So it seems like a non-starter on AMD64 for the current development stack without some other type of workaround. Here's some other ideas we might explore:
I definitely prefer Vagrant overall, since I really like having the dev environment be a VM that's practically identical to production. But if it's difficult or impossible to get it to work on M1/M2 that's a problem, that will prevent a lot of people from being able to set up a dev version.
I think if there's some kind of alternative Vagrant provider that can actually work that's probably the simplest option. For example, when I did a bit of searching about this I saw some mentions of a QEMU provider, but I don't know if it would work for this setup.
Docker is an option if necessary, but it will probably end up being more annoying to set up initially and support.
Either way, I appreciate you and @Maxi (and anyone else) trying to look into it, it's difficult for me to figure anything out since I have no way to actually test it myself.
The Bad News
I tried two alternate provider plugins that seemed promising on M1.
The Good News
In my travails I stumbled upon lima which provides a pretty good experience for mac users. I was able to spin up a debian 10 image and now I'm just working through the ansible playbook to weed out any errors.
So best case, vagrant-libvirt gets sorted out and Apple silicon users can use qemu for development. Worst case we add one more yml file (which looks very similar to the Vagrantfile) to use Lima.
Still a work in progress. I need to find out how to deal with those local paths, and sort out some permissions errors during the provisioning. But if you're ok with another build file I think this could work.
(@Maxi)
Oooh that looks very promising. A single extra build file shouldn't be a problem, even if @Deimos doesn't want it into the main branch/repo, it can always be kept in e.g. a separate fork that's just kept up to date with the main one.
Thanks!
Me and another guy are now looking in to a few different options that'd enable local development on M1/M2 hardware. Going full Docker would be the nuclear option, which would require the most work. We'll keep everyone update if we manage to get something working :)
Yeah I bumped into those same pages.
I also tried a separate approach where I used Docker as a provider for Vagrant - that seemed like a dead end.
I think @Deimos would need to weigh in on what direction he would want to take things. Switching from Vagrant to Docker is a pretty big core change to the project.
We could always make a Dockerfile (as long as we can get it working without any major Ansible changes) and only use that for local M1/M2 development.
Do you get any errors from Vagrant?
Yes, see my other comment here: https://tildes.net/~tildes/165w/tildes_dev_environment_on_apple_silicon_apple_m1#comment-89uu
I think I am forced to alter the Vagrantfile, I was hoping someone else on Apple Silicone had already figured out a solution :P
Regardless, I guess once I figure out a way to get it working, I can put in a suggestion to update the documentation.
Yeah, it's annoying, but kinda expected with new architectures.
This is really far outside my wheelhouse, but if you all think this is worthy of making a Tildes Gitlab issue for, let me know and I can add one. It's so far outside my wheelhouse that I wouldn't even know what to title the issue or how to describe it though, so you would have to let me know that too. :P
I’ll spend a bit of time later today or tomorrow and look into this, I can make either an issue or a pull request depending on what my findings are :p
That would be much appreciated... since I have no idea what I'm doing when it comes to the dev environment. :P
This was discussed in a previous comment I made here.
In this comment thread, you will find old gitlab issues for this and attempts to get tildes dockerized. There was a previous attempt here that got pretty far, but the guy never kept it updated.
AFAIK, it will be a very in depth process to transfer over to docker from vagrant at this point in time, and will require ongoing maintenance.
As someone with decades in IT Ops and deeper knowledge of containers than I like, let me dig a little into this tomorrow.
A good suite of Dockerfiles and a Compose YAML shouldn’t be more work to maintain than a Vagrant box.