Canonical Multipass – Ubuntu VMs on demand for any workstation
multipass.runHoping for canonical's sake I've just got a broken install, cause the UX is somewhere between nonexistent and useless.
Install & restart. Nothing happens. OK lets launch it. Nothing happens. Lets try that again. Nothing happens. Check windows notification area...ah three copies running silently now. Left click on one. Nothing happens. Right click & close two. Spot a open shell thing in the menu. Click on that it starts a powershell window that says "Starting primary" for 5 mins. No idea what that means but I guess it did uhm something. And then closes itself. Staring at empty (windows) desktop again.
Right click on menu again...says "Start primary" is Running. I don't see anything? Let's try the shell again...open a powershell window which instantly closes itself? Back to staring at my wallpaper.
OK let's try stopping this mystery thing that is apparently running. Nothing happens. Try to start it. Nothing. Try the shell again. Now its back to the 5 mins of "Starting primary".
Window disappears. Again.
OK lets try this a different way. Open my own powershell window copy command it. 5 mins of "Starting foo" later.
>launch failed: The following errors occurred: >foo: timed out waiting for response
...and uninstall
Is virtualization enabled in your BIOS? I don't know if that's the problem but I remember having comparable low-information results when trying WSL the first time.
Should be yeah. WSL 1 and 2 works fine so I assume the virt extensions are active. Will take another look tomorrow though
It's in their docs, but not on this page. If you're confused about what this is:
"Multipass is a mini-cloud on your workstation using native hypervisors of all the supported plaforms (Windows, macOS and Linux)"
(Which sounds a bit like docker desktop, just using VMs instead of containers)
I've been running multipass for awhile now to host Docker on macOS, especially on M1. I ended up writing a guide/docs on how to easily get it setup with cloud-init to replace Docker Desktop. Hope this helps anyone.
Did you notice any performance differences compared to Docker Desktop?
night and day. it's the reason I sought out something like multipass. I first started with a license for Parallels Desktop and noticed the disk performance to be way better. Once I came around to multipass, I ditched Parallels Desktop because I liked having cloud-init support, so all my workstations can easily spin that up when setting them up on a fresh-install or a new machine. I have my own dotfiles so automating all of that was a win. Also the auto-mounting of the home directory was a nice touch so I could bind volumes like Docker Desktop does out of the box for you. I would say if you aren't doing heavy i/o across binded volumes you might not notice. But for a client of mine I was having Docker do some large C++ compiles of a project that even after bumping up the cores + memory of Docker Desktop, still felt slow. When trying Parallels Desktop and multipass it felt way snappier and compile times were heavily reduced.
previous discussion: https://news.ycombinator.com/item?id=21836528
Seeing how often virtualbox breaks things and the swiftness with which this spins up a throwaway vm, it has some potential for a faster dev project host.
Don't forget that oracle lawyers will send you a big invoice if they see you using virtual box + guest addons from a company machine.
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 am pretty sure it works as user on ubuntu, just like their lxc containers (main reason I prefer them to docker)
you may need to set it up as root and join the required group, but after that you should not need root.
That is not the way it is working on macOS (nor the way it should work at all).
I assume you mean being user and in the multipass group is not the way you want it.
How should it work then?
I should not need to add myself to the Multipass group nor need any under the hood configuration changes. It should just work for non-admins, although some things like updating should require an admin password.
Off topic but prompted because Fedora and Ubuntu sites keep pushing in this direction... Do you use snap or flatpak? Preferring not to learn a new technology in this space, I've stuck with apt-get and dnf. I guess the dichotomy is that snap/flatpak are for (desktop) applications whereas the system package managers are more for system packages? Neither flatpak or snap seem very common outside of desktop environments (i.e. server deploys or Docker environments).
Curious to hear from others about your experience with either flatpak or snap.
First off, do yourself a favor and avoid snap like plague. It's vendor lock-in and horrible.
I use flatpak precisely as you describe. It's for graphical desktop applications, "apps", basically stuff like Firefox, Libreoffice etc. Sandboxing is cool but I mostly do this because the flatpaks are always up to date with respect to upstream, instead of locked into a particular version like in the system repos. I also recently ran into a situation where a particular application wasn't feasibly packageable by the distribution because of unorthodox dependecy choices (and their own, rather strict rules related to packaging), yet they made a flatpak available.
I also like the fact that the applications and their files are isolated in their respective directories, which makes purging unused stuff easy, as opposed to traditionally packaged software pooping all over my home directory.
Running stuff from the command line is a pain, thus why, at least in my use, it's limited to graphical desktop stuff that I'd anyway run by clicking on an icon.
You can only connect to one Snap repo at a time (which is by default the proprietary Snap Store), unlike Flatpak which supports multiple backends simultaneously.
Canonical is being very sneaky with their promotion of Snaps, with some packages such as Chromium when installed with `apt install` actually installs both Snap and the Snap version of Chromium.
For these reasons I avoid Snaps completely and I have no issues with Flatpak.
Note that the chromium apt package is a transitional package only meant to be used during an upgrade, to migrate existing users. The package is marked as such and the description explains this clearly. Because the package is marked as transitional, it isn't shown in GUIs, it's only installable via the CLI.
The confusion comes mostly from people running the apt command in the CLI without looking at what the package is. There isn't a good way to transition existing users from the deb to the snap during an upgrade without having a transitional package with the same name as the original deb.
Users shouldn't be "transitioned" to a closed-source app store full stop, no matter how nice it would be for Canonical metrics. Only specifically typing `snap install` should work.
If they don't want to continue making auditable builds for this package then that's fine, but they should also stop knowingly making these disguised Snap installation packages which just leverage the package's popularity to increase Snap usage.
> If they don't want to continue making auditable builds for this package then that's fine...
You're mistaken if you think this is what is going on. The build is as auditable as any deb. Here's the source repository:
https://code.launchpad.net/~chromium-team/chromium-browser/+...
...and here are the build logs:
https://launchpad.net/~chromium-team/+snap/chromium-snap-fro...
I found these following links from the store listing: https://snapcraft.io/chromium
Snaps are also used to ship proprietary software - just as proprietary debs also exist. You may not be able to find sources or build logs for those - for example if they are built externally and the binary snap builds uploaded to the store directly. So an individual snap maintainer has a choice on where to build a snap and whether to publish sources and build logs or not. But typically Free Software snaps are built on the same infrastructure as Ubuntu itself, and for these, the sources and build logs are available in an equivalent way.
I use both. Flatpaks usually slightly faster for desktop apps, and snaps can do what flatpaks can’t- entire stack of technologies inside a single snap (nextcloud server for example). The main benefit of both for consumers is general availability of fresh software no mater what distro you’re using and additional security for the price of slightly less performance and additional storage space.
From the security perspective both snaps and flatpaks are preferable to dep/rpm for browsers, email clients, office suite, document viewers and other stuff that is used to parse untrusted data often (due to [wip] sandboxing and auto update).
Snap packages are better maintained (more often with direct involvement of the app developer) and generally receive updates a bit earlier than flatpak. In both cases you need to pay attention who the app maintainer is and I'd argue that in case of unknown maintaners deb/rpm packages are safer choice.
> From the security perspective both snaps and flatpaks are preferable to dep/rpm
Most of the packages still have access to the home directory of the running user, right? The sandboxing almost always seems either configure to be as lax as possible or so strict so that it causes issues. For most desktop linux users if a app has access to their home directory and network access then it already has 99% of interesting things.
Snaps have only limited access to your home directory and you can turn it off as a user. They don't have access to hidden folders in your home directory, for example, so they can't access your ssh keys, config and keychain.
Flatpaks are more an "all-or-nothing" approach. Either the app is in a tight sandbox and uses portals to access things like the camera or it has almost complete access to your os. Since portals are a new API which requires app rewrite, most Flatpaks are not sandboxed.
Also AppImage. I hate them all. It's just lazy developers who won't package their software for each distro. In fairness I get it - that's a lot of CD pipelines. But it really is a second rate experience for the user, compared to a properly packaged app in a repo, which you can install or update with a single command, and which properly integrates with the desktop and doesn't create a bazillion weird mounts.
AppImages are great, I don't know what you're talking about. And they can be easily integrated into a desktop with appimaged, which is what I use to auto-integrate Mochi, Radicle and Lens.
I disagree. Maybe it seems great if you're used to Windows or Mac, where it has always been normal to download files from 50 different websites and run them. No GPG keys, no trust, just run it. I've been using xubuntu for years, and have gotten used to having the command 'apt-get install <whatever>' install an app that integrate with the desktop by default, and a single command to upgrade all of my shit. Suddenly, because application packaging is old and boring, I have to care about some file I'm downloading and from some website. And then I have to install some other hack to properly integrate "images" into my desktop (which doesn't always work, so you create an issue on the hack project and the maintainer bitches about 'badly made AppImages') ...
Next thing you'll be telling me that I should be installing antivirus to make sure the plethora of downloaded files don't contain malware.
And if I don't bookmark all the sites where I'm supposed to get these images, I have to hunt them all down again. And if I don't bother doing that I'm running old versions of everything.
Screw all of that and give me my apt-get install / upgrade.
For the two AppImages I am forced to use, I actually ended up writing a bash script to download them, mount them and build a .deb file that does the desktop integration. Then I push the .deb to my own repo, so apt-get install/upgrade works across all my machines again.
Snap can install non-desktop applications just fine. I've only ever seen Flatpak for desktop apps, but I use snap for installing things like docker, lxd etc.
Isn't the entire point of snaps (and flatpaks?) technology that it's isolated? So the application won't be able to do whatever to your computer. But docker, lxd and similar usually requires root permissions to run, and access to bunch of sockets and what not.
Isolation is optional and you can tune it to your needs.
Yes, I used snap on server, I think the package was pdftk , worked great the only issue it might be is that is configured to only have access to the home folder.
Snap is a good solution if there is no alternative in the repositories or the one there is too old.
This is what I do for the desktop apps for my home desktop:
If a package is in the Fedora repository, I favor getting it from there. If it is not, my first choice is a flatpak from Flathub. I find it much less painful than downloading RPM packages (which aren't always provided and also don't automatically update) or adding a bunch of third party repositories like PPAs (which have a tendency to cause dependency hell if there are too many of them).
The main exception is the RPMFusion third-party repository. If something is in RPMFusion I get it from there instead of trying the flatpak. (Examples include Steam and FFmpeg)
I use Ubuntu on the desktop, have a few snaps installed and a couple if flatpaks. Both seem fine in my limited usage.
Snaps are also available for servers and IOT devices. AFAIK the popular EFF Certbot is only distributed via snap for example.
AppImage. And I aggressively cut snap away.
I use neither, I tried to use both, but my main driver is a latop and even though I have a 1TB SSD I consider this to be eating a significant portion of my disk space. electron apps already are disk hungry enough on their own.
Note that, because snaps are stored compressed on disk, many snaps are smaller on disk than their regular package counterpart. Take the chromium package as an example.
However, a bunch of snaps are full of unused libraries because a bunch of packagers use a shotgun approach to including libraries. I've seen a bunch of snaps which contain the entire build environment for the app itself, for example. After cleanup, such snaps are often only 1/3 of the original size.
Because many snaps are created by app devs themselves, they don't all have the same quality as packages from the debian repository.
No sorry, and for good reason: https://gioorgi.com/2021/ubuntu-20-failed-me/
Snap update package without control and it is not open source…
Silly question, what do you use Multipass for? I mean, real world applications for these VMs, do you use it for continuos integration, server prototyping? To isolate frameworks/APIs?
Just curious - are there anyone using this at scale? Multipass has existed for quite some time and I frequently go back to the website to check for new features but always see the same thing.
Ubuntu seems to use it in their infrastructure and services, so yeah.
I'm quoting their copy here to make sure my criticism is accurate:
> Ubuntu VMs on demand for any workstation
What does this get me over VirtualBox?
> Get an instant Ubuntu VM with a single command.
Vagrant? Maybe the "single command" is good? Am I just being too much of a mounting-it-locally-with-curlftpfs guy?
> Multipass can launch and run virtual machines and configure them with cloud-init like a public cloud.
I am already confused. Are these VMs on a public cloud or not? If they are on my local machine, it's not really a test of the cloud (hint: Testing problems with virtual machines is not the difficult part of simulating a cloud on your computer, testing the possible failures with the other 200- hosted message queues and databases is). Again, what is this getting me over Vagrant or Virtualbox?
> Prototype your cloud launches locally for free.
I am still at a loss to understand what exactly is the selling point of this tool. Is it literally just "vagrant, but for Ubuntu"? I really don't get it.
It may be popping up in the news again because Canonical just announced M1 support for multipass on macOS[1]. I haven't tried it, but I do appreciate the reference to The Fifth Element.
1: https://ubuntu.com/blog/canonical-transforms-linux-on-mac
That‘s why and how I found it.
The docs seems to explain things the best, as usual:
> Multipass is a mini-cloud on your workstation using native hypervisors of all the supported plaforms (Windows, macOS and Linux),
Seems their innovation is "Docker, but after 8 years of Docker"
What about Canonical's LXD/LXC?
It seems faster than Vagrant to me, and doesn't rely on VirtualBox (it uses Hyper-V on Windows, KVM on Linux, and Apple's Hypervisor API on macOS). Granted, Vagrant doesn't either, but very few of the boxes have support for the native hypervisors.
Yes it's been way faster for me over Virtualbox. It's how I run docker now from macOS. I've been testing out the M1 support for few months now.
> Is it literally just "vagrant, but for Ubuntu"?
Yes. It doesn't seem very confusing to me?
I might be wrong about this - I have a history of sometimes not always understanding technology before I discard it. However, I briefly used Multipass but switched back to Vagrant. To me, it was a new tech that did the same as the old tech only with the usual new tech adoption muck ups.
However, I might be wrong. Maybe I just missed the point of it?
Cloud-Init is a local tool for setting up a new fresh system instance. It isn't tied to any real cloud.
I'm with you - this seems like docker for ubuntu.
that's how ive been running it on macOS. I put up a guide https://github.com/chrisgoffinet/docker-multipass