multipass

They do document how to build and run, in the OS specific build docs. Eg this: https://github.com/canonical/multipass/blob/main/BUILD.linux... I think pointing end users to use the end user packaged app is fine, as is to trust people who are comfortable with building from source to find the build docs from the repo.

I love multipass. It is a simple no BS virtualization solution and probably the best thing to come out of Ubuntu after LXD. But I can't use it. You know why? Because despite being open source Canonical wont tell you how to compile it and install it as a standalone program. Instead all their documentation says "install via snap"... even if your are on fedora or debian or arch: https://github.com/canonical/multipass Snap needs to die, it is hurting everybody including canonical

FYI there is an unofficial package in aur that I prefer as well to snap Note there is a minor tweak needed after install to put efi firmware in spot where it looks https://github.com/canonical/multipass/issues/3441 https://aur.archlinux.org/packages/canonical-multipass

Appears perhaps not unless things have changed or feature added since this: https://github.com/canonical/multipass/issues/2503

I liked Multipass until I ran into storage corruption issues like many others [1][2] and broke all my VMs. On MacOS, Multipass uses qemu in which the apple-hvf support isn't getting much updates after 2021 [3]. [1]: https://github.com/canonical/multipass/issues/3455 [2]: https://github.com/canonical/multipass/issues/3235 [3]: https://github.com/qemu/qemu/commits/master/accel/hvf

Multipass is pretty clutch for trivial VMs on MacOs for sure. I use it for a bunch of ssh jump boxes running vpns to different sites. The macOS build does not support custom images (lest not without [some truly insane hacks](https://github.com/canonical/multipass/issues/1260#issuecomm...) , which doesn’t really matter for what I use it for but it is kind of a bummer. If you need something with a little more grunt but don’t want to go full blown with writing your own QEMU tooling or fussing with something like UTM or Parallels, [quickemu](https://github.com/quickemu-project/quickemu) is a really nice qemu wrapper with sane defaults that can expose a whole lot of power if you need it.

Mask can't directly solve this problem by itself, it just runs whatever script you give it. If you can write a python/js/bash/etc script to achieve what you want, you can stick it inside a maskfile with the rest of your commands. Regarding docker, I haven't tried it on M1 yet. However, I've been using Ubuntu multipass [1] for over a year now and I'm very happy with it. It makes it easy to set up and manage VMs for different projects, and it seems to run very efficiently on macOS in my experience. When a project needs a docker container like postgres, I just run docker compose inside the VM rather than running it directly in macOS. You can also limit the amount of CPU/RAM the VM uses to keep things under control. [1]: https://github.com/canonical/multipass

Multipass is awesome (lightweight) but a no go for some unless this issue is resolved : https://github.com/canonical/multipass/issues/2387

I liked the idea of it until I realized I could not run it as a non-admin user on the Mac because they had not designed the app in a way that allowed for it - the control socket was inaccessible to my "regular" user. Issue has been open since March 2020: https://github.com/canonical/multipass/issues/1437

I believe this is the issue referenced above: https://github.com/canonical/multipass/issues/1857

multipass supports two hard-coded remotes, `release:` and `snapcraft:`. It should be feasible to be able to launch any of the VM images from LXD (i.e. https://us.images.linuxcontainers.org/), as long as there was a way to add a new _remote_. edit: there is a pending issue https://github.com/canonical/multipass/issues/307

Worth noting that Multipass does not support launching VMs with bridged networking. See this issue for details: https://github.com/canonical/multipass/issues/118 This means that your VMs won't be able to get IP addresses on your LAN via DHCP. Kind of a fundamental omission for this kind of product I would think. Curious that it's not a high priority issue for them. Also, what's the IPv6 story here? I didn't see anything in the docs addressing that, unless I'm missing something.