Closed frankban closed 11 months ago
Similarly for me .. A typical pattern is to: 1) start with a vanilla ubuntu image 2) add a bunch of developer stuff (compile / k8s / other) 3) snapshot that before I start doing other work, so that I can easily get back to that initial start, and/or use it as a basis for another project.
And of course this helps with the airplane / offline mode.
On my current workflow i use Vagrant and Ansible which i can easily reproduce with multipass
and in fact I have noticed faster VM creation/start times when comparing with Vagrant (both tested on Linux and MacOS). This environment can be easily shared among developers and is reproducible but some times there is need to spin off a fresh VM without having to wait for provisioning scripts (Bash, Ansible, etc.) to finish their job (e.g. demos). Vagrant has this feature where you can create a snapshot and store it to a repo and use that URL for the base image. Similarly, when working with LXD images i can share the images directly with colleagues or push them to an internal registry. Maybe consider it for a future enhancement.
Keep up the good work
+1
Preparing the development environment based on a Ubuntu cloud image, then take a snapshot as the baseline. Re-start from there as often as needed.
Did anybody try to manipulate multipassd-instance-image-records.json? Could I just copy over an existing instance directory and "make it available" as a new instance?
Hi @swissguest, note that the instances get "initialized" on first boot, and there's things that might not work as you expect if you do just that. At least one thing that comes to mind is hostname, which would conflict if you just copied the instance disk image. Your mileage may vary ;)
will this be implemented? Really like multipass but without this feature I'll have to reluctantly have to use something else ...
I agree with this specific topic. Two options: One should be able to create images from instances, such that they can be recalled to create new instances. This would fit the current model.
The other would be to simply save state of the instance and peruse different state names with time stamps. Allowing the workflows described above, which I abundantly use as well.
I am surprised and disappointed that this issue is still open after 2+ years. Why Multipass? I've used LXD extensively for over 3 years and this seems to be a step backwards not forwards. The ability to save, replicate and move instances is a basic feature set needed to make this a viable development environment. Yes/no ?
@mrb1090 Multipass isn't for everyone. If you're comfortable with LXD, you can keep using it. Multipass works with VMs, not containers like LXD by default, and not just on Linux. They complement each other, rather than replacing.
@Saviq It's not just LXD, though. Most VM management tools support snapshots, e.g. virt-manager, virtualbox. And it can't be too long until LXD is on Windows via WSL2, eh?
@Saviq It's not just LXD, though. Most VM management tools support snapshots, e.g. virt-manager, virtualbox. And it can't be too long until LXD is on Windows via WSL2, eh?
Can't comment on the latter, but it's not like we closed this issue. We just have higher priority items to work on, first :)
Snapshots are a complex topic, different hypervisors deal with them differently (or not at all), cloning adds to the complexity even more. We just have to prepare to it well, to maintain good UX.
Adding my two cents for snapshots. I use it in the same method mentioned above--configure a machine; snapshot it; then do testing/demos/whatnot and return to the clean snapshotted version when I'm done. Possibly offer an option to change the root filesystem to something that supports snapshots?
Hello, This week I install and recreate all my VM 4 times because of this:
list failed: cannot connect to the multipass socket
Please ensure multipassd is running and '/var/run/multipass_socket' is accessible
I'm on OSX Big Sur / Intel with Multipass 1.6.2
Every time, I was obliged to uninstall all (even drop the VMs and daemon data)
A snapshot feature would be useful, but I'm totally ok with a workaround. is there a procedure to be able to recover existing VMs? or to solve this "socket" issue?
Hi @k33g, sorry you're experiencing that. When this next happens, could you please check if the version linked here helps (without removing instances and data)?
A related use case that would be handy is to allow snapshotting and allow publishing the image (locally) such that other instances be can launch from it.
Hi @k33g, sorry you're experiencing that. When this next happens, could you please check if the version linked here helps (without removing instances and data)?
@ricab sure!
Hi,
I also would love to have this feature. A simple short term solution would be to allow deploying qcow2 images when using the libvirt driver. Then you could at least use virsh to snapshot.
Are there any workarounds on creating a backup or snapshot of a Multipass instance for macOS, Ubuntu OS?
There is a description of a possible work-around here, although I have not tried it: https://askubuntu.com/questions/1180895/import-export-vms-from-multipass . Related https://snapcraft.io/docs/snapshots
Are there any workarounds on creating a backup or snapshot of a Multipass instance for macOS, Ubuntu OS?
What I do to create a snapshot on macOS is:
cd /var/root/Library/Application\ Support/multipassd/qemu/vault/instances/<instance-name>
mv ubuntu-20.04-server-cloudimg-arm64.img base.img
base.img
as the backing file:
qemu-img create -f qcow2 -F qcow2 -b base.img head.img
head.img
named ubuntu-20.04-server-cloudimg-arm64.img
:
ln -s head.img ubuntu-20.04-server-cloudimg-arm64.img
If you want to rollback to base.img
you can simply adjust the soft link of delete and re-create the "delta" file head.img
.
If you want to commit the changes made in head
to base
you can run: qemu-img commit head.img
.
I'm on Apple Silicon so Multipass is using QEMU under the hood and some paths may be different compared to an Intel Mac, but I think that this should work with Hyperkit as well.
I'm on Apple Silicon so Multipass is using QEMU under the hood and some paths may be different compared to an Intel Mac, but I think that this should work with Hyperkit as well.
Note Hyperkit is using a different implementation of qcow2 support with quite some limitations and incompatibilities. Part of why we want to move to QEMU across the board. It will also enable us to think about this feature again.
I'm on Apple Silicon so Multipass is using QEMU under the hood and some paths may be different compared to an Intel Mac, but I think that this should work with Hyperkit as well.
Note Hyperkit is using a different implementation of qcow2 support with quite some limitations and incompatibilities. Part of why we want to move to QEMU across the board. It will also enable us to think about this feature again.
Thank you for the clarification, I've edited my comment
I have found an easy way to backup the multipass instances if you are using windows virtualbox as the driver. 1) referring to https://multipass.run/docs/using-virtualbox-in-multipass-windows, download the pstools and run & PsExec.exe -s -i $env:VBOX_MSI_INSTALL_PATH\VirtualBox.exe 2) the VirtualBox Manager GUI will be shown, you can then clone the instance 3) after cloning the instance, close the GUI and you can double-click the .vbox file created to launch the normal virtualBox GUI 4) you can do whatever you want to the cloned instance (clone more or create snapshot, etc) on the virtualbox manager Don't know if this is work for linux virtualbox.
I have found an easy way to backup the multipass instances if you are using windows virtualbox as the driver.
- referring to https://multipass.run/docs/using-virtualbox-in-multipass-windows, download the pstools and run & PsExec.exe -s -i $env:VBOX_MSI_INSTALL_PATH\VirtualBox.exe
- the VirtualBox Manager GUI will be shown, you can then clone the instance
- after cloning the instance, close the GUI and you can double-click the .vbox file created to launch the normal virtualBox GUI
- you can do whatever you want to the cloned instance (clone more or create snapshot, etc) on the virtualbox manager Don't know if this is work for linux virtualbox.
Thanks!
Multipass does not recognize the cloned VM created throught Virtualbox GUI. However, if you follow steps below, you can control the cloned VM with multipass commands.
Now, you have full controle of cloned VM with multipass commands. I hope that Multipass implements snapshots and clone functions like vagrant does, which are very useful for a developing environment.
I used an above method to control VM from multipass.
However, information of cloned VMs suddenly disappeared from the setting file and Multipass could not recognize those VMs although they remained in Virtualbox. I tried to fix it, but I was not able to do so.
Since Multipass does not support clone officially, this can happen anytime. So, I had to give up using Multipass and went back to Vagrant. I hope Multipass will support a backup in the future.
你好@swissguest,请注意,实例首时会被初始化初始化初始化初始化初始化初始化会发生冲突。你的旅费可能会改变;)
那么我可以通过更改 multipassd-instance-image-records.json,multipassd-vm-instances.json这两个文件来实现容器复制和注册吗?
Any news on this? It's been quite a while, would be interesting to know if this will be on the backlog or a wontfix
feature.
Hi @lowercase00, we will finally start work on snapshots soon!
Coming by and wondering whats the status is. Today I've finished my dev setup in a ubuntu multipass vm on apple silicon. Took me a few days to make all the tools work that I needed but I totally amazed about the performance of the virtualization.
However, I've just realized to my surprise that there is no snapshot/backup option. In case of a fatal failure in the VM I would have to start over. Anyway, thanks for the great work.
Hi @rene-hermenau, thanks for the kind words.
We have an implementation of the QEMU-specific and generic bits that is close to being done. We then have to implement other backends too. Here's where you can track our progress on snapshots. And the feature branch.
For those who need it, here is a Linux solution I use to snapshot all multipass instances and restore them to a new host.
multipass is great, among other usages, for setting up isolated development environments. For instance, users are able to contribute to projects requiring a specific version of ubuntu thanks to multipass: creating and starting instances is very simple and the whole experience feels lightweight and clean. Those are intended to be long-living instances, and therefore having the ability to create snapshots and backups would be very useful.