Skip to content

Commit aeb5f49

Browse files
committed
doc: clarify cross-kernel snapshot compatibility
Simplify by just making the statement that we do not recommend it, and it generally doesnt work except for one limited case. Simplify the table by only listing what's working, an by having the first column directly refer to instance types (instead of cpu architectures, which we later map to instance types in the text). Closes #4912 Signed-off-by: Patrick Roy <[email protected]>
1 parent f6bd4b6 commit aeb5f49

File tree

1 file changed

+14
-22
lines changed

1 file changed

+14
-22
lines changed

docs/snapshotting/snapshot-support.md

+14-22
Original file line numberDiff line numberDiff line change
@@ -25,6 +25,7 @@
2525
- [Secure and insecure usage examples](#usage-examples)
2626
- [Reusing snapshotted states securely](#reusing-snapshotted-states-securely)
2727
- [Vsock device limitation](#vsock-device-limitation)
28+
- [Where can I resume my snapshots?](#where-can-i-resume-my-snapshots)
2829

2930
## About microVM snapshotting
3031

@@ -638,28 +639,19 @@ might not be able to handle the injected notification and crash. We suggest to
638639
users that they take snapshots only after the guest kernel has completed
639640
booting, to avoid this issue.
640641

641-
## Snapshot compatibility across kernel versions
642+
## Where can I resume my snapshots?
642643

643-
We have a mechanism in place to experiment with snapshot compatibility across
644-
supported host kernel versions by generating snapshot artifacts through
645-
[this test](../../tests/integration_tests/functional/test_snapshot_phase1.py)
646-
and checking devices' functionality using
647-
[this test](../../tests/integration_tests/functional/test_snapshot_restore_cross_kernel.py).
648-
The test restores the snapshot and ensures that all the devices set-up (network
649-
devices, disk, vsock, balloon and MMDS) are operational post-load.
644+
Snapshots must be resumed on an software and hardware configuration which is
645+
identical to what they were generated on. However, in limited cases, snapshots
646+
can be resumed on identical hardware instances where they were taken on, but
647+
using newer host kernel versions. While we do not provide any guarantees on this
648+
setup (and do not recommend doing this in production), we are currently aware of
649+
the compatibility table reported below:
650650

651-
In those tests the instance is fixed, except some combinations where we also
652-
test across the same CPU family (Intel x86, Gravitons). In general cross-CPU
653-
snapshots [are not supported](./versioning.md#cpu-model)
651+
| .metal instance type | taken on host kernel | restored on host kernel |
652+
| -------------------- | -------------------- | ----------------------- |
653+
| {c5n,m5n,m6i,m6a} | 5.10 | 6.1 |
654654

655-
The tables below reflect the snapshot compatibility observed on the AWS
656-
instances we support.
657-
658-
**all** means all currently supported Intel/AMD/ARM metal instances (m6g, m7g,
659-
m5n, c5n, m6i, m6a). It does not mean cross-instance, i.e. a snapshot taken on
660-
m6i won't work on an m6g instance.
661-
662-
| *CPU family* | *taken on host kernel* | *restored on host kernel* | *working?* |
663-
| ------------ | ---------------------- | ------------------------- | ---------- |
664-
| **x86_64** | 5.10 | 6.1 | Y |
665-
| **x86_64** | 6.1 | 5.10 | N |
655+
For example, a snapshot taken on a m6i.metal host running a 5.10 host kernel can
656+
be restored on a different m6i.metal host running a 6.1 host kernel (but not
657+
vice versa), but could not be restored on a c5n.metal host.

0 commit comments

Comments
 (0)