Feel free to just shoot this down, but I can’t be denied if I don’t ask. 
Would there be interest from the Incus team in adding support for running as a virtualization manager on MacOS? Obviously container support would not work, and only a subset of features would work.
Thoughts?
(Also, I realized my own issue creating topics in the wrong place 
)
That would be interesting and there was some limited interest way back in the past about doing something similar on Windows.
Indeed containers wouldn’t work but the VM side of things should be okay.
I’d definitely be happy to help anyone attempting to do this work. A number of refactoring and changes would likely be needed so that Incus can be built without some of its storage drivers, network drivers and most importantly, without container support, but I don’t see any fundamental reason why it wouldn’t work.
If someone really really wanted this to happen and didn’t want to do it themselves, it’s something I could look at doing on a contract, but it likely wouldn’t come in particularly cheap as getting something up and running would likely take me about a month of work and I’d also need to include the cost of some Apple hardware as I don’t own any Mac myself. That Apple hardware would then also have to be added to our lab so automated testing can be done to prevent any regressions. A very rough estimate would be in the 40-50k CAD should someone want to sponsor that.
PS: Doing that work for MacOS would also remove much of the roadblocks in the way of doing the same thing for Windows. MacOS should be easier thanks to being a UNIX OS, but the same code changes around storage/network/instance apply to both.
Thanks for the response! I’m a huge fan of what you’ve built and want to use it more widely. Unfortunately, I don’t have a company to back me in this so it would just my desire to expand Incus’s reach.
I would consider helping fund some Mac hardware, but I sadly wouldn’t be able to contribute enough to probably make this happen through funds alone.
It’s good to know you’re open to the possibility in the future.
Yeah, we’ve definitely always had the idea of supporting running the daemon on other platforms, that’s why the OS is reported in the metadata. Initially we had some hopes of getting Windows containers support, but that didn’t really end up going anywhere.
Now that we have VM support, that part of the story is a bit more straightforward as QEMU works on both Windows and MacOS, so the main difficulty is in refactoring the code to allow building without any of the Linux bits and also dealing with the different network and storage components.
If someone is interested in helping make this happen on the technical side of things.
I’d probably start by making sure that cowsql behaves on MacOS as without it, we’re not going to get very far. Once that works properly, then the next step would be to add a bunch of build tags, basically making it so the entire lxc driver and most of the forkXYZ sub-commands all require a linux system to be built. With that done, then you can finally start building on MacOS and see what kind of issue you hit and take it from there
Looks like cowsql/raft is currently preventing this: https://github.com/cowsql/raft/blob/55a0873eba7b3a60317c4ee0e78522c3700ac005/configure.ac#L82-L86
Yeah, but it’s something that we could motivate @freeekanayaka to relax if there was interest. We may need to initially limit it, potentially not allowing clustering or having some pretty clear caveats around how the filesystem access is handled.
@freeekanayaka is the creator of dqlite/libraft and now the maintainer of its community fork, cowsql. He was also part of the LXD team at Canonical and is the one who implemented the bulk of LXD clustering back then.
Sorry for the late reply, I had missed this.
I’d be definitely interested in having cowsql work on MacOS, and I don’t think it’s that difficult.