micro VM snapshotting support

[kzys]

Firecracker's next release will have microVM snapshotting. The API definition file has been updated on master already (see #233).

[kzys]

Firecracker v0.22.0 doesn't have snapshotting. We are going to release the SDK's v0.22.0 to address breaking changes first.

[kzys]

Note to myself, we have Pause, Resume and CreateSnapshot. Loading from a snapshot (restore) is still pending. It would need some redesign of the Machine abstraction we have.

[MNThomson]

Restoring from a snapshot would be a highly appreciated feature, any updates on progress or timeline?
Thx!

[ustiugov]

vHive has complete support for snapshots in a research-tailored frameowork, integrating Knative, Kubernetes, and Firecracker. If you are interested in the snapshot support only, you can take a look at our changes in firecracker-containerd fork.

[alexellis]

Hi @kzys

I'm interested in using this feature in Firecracker

Note to myself, we have Pause, Resume and CreateSnapshot. Loading from a snapshot (restore) is still pending. It would need some redesign of the Machine abstraction we have.

It looks like milestone 1.0.0 was opened on 4 Jun 2020 - quite some time ago.

When do you expect to see LoadSnapshot in the Go SDK?

Could machines be created with the Go SDK using CNI, and then restored by manually creating a firecracker process and using the unix socket's HTTP API as per the Snapshot API?

Do you see any issues with CNI and the names of the tap adapters?

[Joffref]

Hello @alexellis,

Quick disclaimer, I'm not part of the dev team and everything that follows reflect only my knowledge of the SDK.

At this time, LoadSnapshot works very well, but it's not available in v0.22, so it will be usable in the next version of the SDK.

You can create a machine with the go SDK, snapshot it and then use firecracker API to restore the VM. As you mentioned restoring with network is a big deal, you can restore a VM but as described in this documentation you must follow some basics steps to ensure VM will properly retrieve its connectivity. I think the main issue is to store somewhere the VM IP and tapName (if not setted using the SDK it's the machine ID) and then be able to restore with the proper CNI configuration.

As I understand your last question (if it's also related to this issue : awslabs/tc-redirect-tap#12) and after digging into the tc-redirect-tap code, it seems that there is an argurment avoiding tapName to be random, that is used by this function and called in add plugin method.