|
25 | 25 | - [Secure and insecure usage examples](#usage-examples)
|
26 | 26 | - [Reusing snapshotted states securely](#reusing-snapshotted-states-securely)
|
27 | 27 | - [Vsock device limitation](#vsock-device-limitation)
|
| 28 | +- [Where can I resume my snapshots?](#where-can-i-resume-my-snapshots) |
28 | 29 |
|
29 | 30 | ## About microVM snapshotting
|
30 | 31 |
|
@@ -638,28 +639,19 @@ might not be able to handle the injected notification and crash. We suggest to
|
638 | 639 | users that they take snapshots only after the guest kernel has completed
|
639 | 640 | booting, to avoid this issue.
|
640 | 641 |
|
641 |
| -## Snapshot compatibility across kernel versions |
| 642 | +## Where can I resume my snapshots? |
642 | 643 |
|
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: |
650 | 650 |
|
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 | |
654 | 654 |
|
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