Add snapshotting functionality

[cweagans]

I would like to be able to create one or more snapshots of a lima vm and be able to roll back to some specified snapshot. I'm thinking this would be a copy of the qcow2 images stored in the ~/.lima/machine-name/ directory. It would be totally fine (and probably desirable) to shut the machine down before making a copy of the images.

This would be useful for e.g. testing a provisioning script. I could set up the machine with a base install of ubuntu, take a snapshot, and then be able to quickly roll back to the base state of the machine without necessarily re-doing the machine from scratch. It could also be useful for testing potentially destructive operations inside the VM.

[afbjorklund]

Duplicate of:

• https://github.com/lima-vm/lima/issues/1051

[vsoch]

Silly question - I saved a snapshot, e.g.,:

$ limactl snapshot create flux-0 --tag flux-instance-gcp-12-17-2023

And I'm wondering where it saves to?

$ limactl snapshot list flux-0
WARN[0000] `limactl snapshot` is experimental           
INFO[0000] Sending HMP info command                     
ID        TAG               VM SIZE                DATE     VM CLOCK     ICOUNT
--        flux-instance-gcp-12-17-2023 3.84 GiB 2023-12-17 12:29:02 00:44:35.838  

I see it uses qemu-img here: https://github.com/lima-vm/lima/pull/1054/files#diff-25a805e06b16efefb1e5acb2009e512cca20865126e3a6afa52df59dcb4cf0fbR158 but I'm not experienced enough to know how to get it. I'd like to be able to export the VM and then, for example, import it into a cloud via storage. Or do I not need a snapshot (which is a diff) and just want one of these files here?

$ ls /home/vanessa/.lima/flux-0/
basedisk    diffdisk  ha.pid   ha.stderr.log  lima.yaml  qmp.sock    serial.sock  serialv.sock  ssh.sock
cidata.iso  ga.sock   ha.sock  ha.stdout.log  qemu.pid   serial.log  serialv.log  ssh.config

If the basedisk is some format I can use, or I can load the iso into a VM image (which I think I know how to do) that might fit the bill - just trying to figure out the right (or recommended) path. Thanks for the help!

[afbjorklund]

The snapshots, like the normal contents, are stored in the diffdisk. The basedisk is the readonly cloud image.

Both are normally in the QCOW2 file format, unless using lima-alpine in which case the basedisk is an ISO image.

You can learn this, using the regular file tool.

The diffdisk has the basedisk, as a "backing file".

https://www.qemu.org/docs/master/system/images.html

You need both files, but the basedisk is the same as in cache.

---

The qemu-img tool can combine the files into one image, and export into various different formats.

It also allows for manipulating the snapshots, but requires that the virtual machine using it is offline.

[vsoch]

You can learn this, using the regular file tool.

Great, thank you! Any reason they don't have an extension so it's obvious to the untrained eye?

[afbjorklund]

Any reason they don't have an extension so it's obvious to the untrained eye?

No particular reason, just UNIX. Like "README", versus "README.txt"?

Think I had to add DOS extensions like .img and .iso, for VirtualBox to work https://github.com/lima-vm/lima/commit/ff5238cf3eafcfc62334ec123c24b4a16fb176ef It would crash without them... Added some symlinks, for the old names. (which of course probably wouldn't work on actual Windows, but anyway)

[vsoch]

Gotcha! And super cool - thanks for giving me this nugget of info. I know about file but didn't consider trying it here (I was going to try opening it in vim to see if there was an identifable header, like with ELF, haha).

$ file basedisk 

basedisk: QEMU QCOW2 Image (v2), 2361393152 bytes

$ file diffdisk 

diffdisk: QEMU QCOW2 Image (v3), has backing file (path /home/vanessa/.lima/flux-0/basedisk), 268435456000 bytes

[afbjorklund]

You can also use qemu-img info, if you want the details.

[vsoch]

Even better!

I was able to load this into GCP and (soon) am going to boot it up. So far no issues!