beringresearch / macpine

Lightweight Linux VMs on MacOS

Home Page:https://beringresearch.github.io/macpine/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Feature] Logical separation between VM images and VM instances?

idroz opened this issue · comments

commented

Archives exported by macpine are VM disk images. It may be desirable to be able to store imported images in .cache and list them using e.g. alpine images. alpine launch could then be used to launch a VM instance using locally-available images (it does it anyway, we just don't expose listing of those local images to the user)

I think that this would add a somewhat unnecessary distinction between things that, to the user, aren't that different.

I think a slightly different feature, snapshotting instances at save points by exporting new .qcow2 files to ~/.macpine/instance-name/snapshots so you can reset an instance immediately into any point in its past you've saved, would be amazing.

Then you could alpine snap instance-name list or alpine snap instance-name restore snap-name (maybe we list them with names and numbers for convenience and support both).

$ alpine snap cheerful-result new "working-mysql"
saving instance state...
snapshot 1. "working-mysql"` created
$ alpine snap cheerful-result list
0. "first-snapshot" 5/5/2023 07:22:36
1. "working-mysql" 5/8/2023 12:45:00
$ alpine snap cheerful-result restore 1
restoring...
cheerful-result restored to "working-mysql"
$ alpine snap cheerful-result delete first-snapshot
snap "first-snapshot" deleted

We'd have to think about how to manage the instance disk file to ensure consistency while the .qcow2 changes underneath, ideally without adding a ton of storage cost.

Maybe a diff-based disk format could be applied here?

Come to think of it, this is basically re-engineering alpine publish in a way that adds a ton of complexity. Tentatively closing.