[Pedro Henrique Penna (ppenna)]

Lets the restore of a microVM platform snapshot whose filesystem slot is dormant attach an aggregate of host directories and files, with its access policy and owner, validated as at a cold boot, before any vCPU runs, for microsoft/nvx#540. This is a new feature of the platform tier rather than a fixup.

Based on feature/microvm/dev. This branch is two commits directly on b92daa350, the head of feature/microvm/dev and the revision that NVX's dev pins.

The device takes a dormant slot's state into an aggregate (057a2eaa6)

A capture that leaves the slot dormant saves a dormant device state, without an attachment, a policy, objects, or an initialized FUSE session, and the device restores it into any attached device, since it restores only the session. microvm_dormant_state_restores_into_aggregate_attachment checks it for the device of an aggregate of a read-write directory and a read-only file, and that the device then saves the aggregate, with its children's kinds and modes, rather than the dormant slot. Only a test changes.

A platform restore attaches an aggregate to a dormant slot (832d5bb48)

• Options. At the restore of a platform snapshot whose slot is dormant, --mount-aggregate with its --mount-child options, and their --mount-deny, --mount-allow, --mount-write, and --mount-owner policy, attach an aggregate to the slot.
• Validation. effective_microvm_filesystem builds it with a cold boot's code, microvm_filesystem_from_request, so the restore checks the children's kinds, modes, names, overlaps, and limits, the policy paths, and the owner as a cold boot does, and refuses what a cold boot refuses, before any vCPU runs.
• Nothing added. The slot's device keeps the stable ID, tag, MMIO range, interrupt, features, and queues that the snapshot recorded, and the guest keeps its captured command line, which names no filesystem: OpenVMM exposes no layout, and the guest learns of the export from its host. The device takes the dormant slot's state as it does for a --mount, and the restore contract still records the dormant slot.
• Tiers. prepare_restore admits the aggregate only for a platform snapshot, which is captured before any tenant input; a later tier carries a workload that ran without a filesystem. The dormant slot of a workload-start, instance-checkpoint, or untiered snapshot still binds only a --mount, a snapshot that predates the dormant slot binds nothing, and a snapshot that captured a filesystem still requires exactly that filesystem.
• Unchanged. --mount, and a restore without an attachment, behave as before. The management API, which describes only a single directory, does not change.

Tests

• virtiofs::microvm::device: microvm_dormant_state_restores_into_aggregate_attachment.
• microvm::filesystem:
  • dormant_slot_restore_attaches_an_aggregate_as_a_cold_boot_does: directory and file children, read-only and read-write, with denied, allowed, and writable paths, resolve to a cold boot's configuration, roots, and identities.
  • dormant_slot_restore_refuses_the_aggregates_that_a_cold_boot_refuses: overlapping directories, a file inside a directory child, a directory or file of the wrong kind, a repeated name, a file child's policy path, a path outside every child, and a relative path, each with a cold boot's error.
  • dormant_slot_restore_applies_the_owner_of_a_cold_boot: --mount-owner caller resolves, or is refused, as at a cold boot.
  • restore_attaches_an_aggregate_only_to_a_dormant_slot, which replaces restore_attaches_an_aggregate_only_where_the_snapshot_did: a snapshot without the dormant slot, and one of a single directory, refuse an aggregate.
  • The tests of captured attachments, such as aggregate_restore_requires_the_same_children and aggregate_restore_requires_the_same_files, and of --mount on a dormant or legacy slot are unchanged.
• microvm::restore: only_a_platform_restore_attaches_an_aggregate_to_a_dormant_slot, for every tier.

Validation

• At this head, on Windows: cargo clippy --all-targets and cargo doc --no-deps for virtiofs and openvmm_entry; cargo nextest run --profile agent for both (339 passed); and cargo xtask fmt --fix (clean).
• Bare metal, with openvmm: let a platform restore attach an aggregate to a dormant filesystem slot nvx#948, which pins this branch and adds the platform-aggregate-export microVM scenario, on Linux/KVM, Linux/MSHV, and Windows/WHP hosts: the scenario, which restores one platform snapshot with an aggregate of directories and files, read-only and read-write, with denied, allowed, and writable paths, passes in 3.4, 4.1, and 9.1 s, and NVX's default microVM suite passes 41/41 on each. The clone's guest finds the aggregate's children with their kinds, modes, and policies, and the restores whose aggregates a cold boot refuses fail before the guest runs with a cold boot's errors, as caller ownership does on Windows, and an untiered snapshot's dormant slot refuses an aggregate. With the unpatched d2338ea22 on MSHV, the capture succeeds and the clone's restore fails at a dormant-slot snapshot can attach only a --mount on restore. Those runs were at d7892ffa8, these two commits on d2338ea22. [DO NOT REVIEW] disk_blob: bound HTTP blob requests and retry transient failures #4773 has since moved feature/microvm/dev to b92daa350 with three commits that change only disk_blob, and git range-diff shows that rebasing onto it left both patches unchanged. With this head, the scenario passes again on the same hosts, in 3.4, 4.3, and 8.8 s, as filesystem-snapshot does, and in openvmm: let a platform restore attach an aggregate to a dormant filesystem slot nvx#948's CI on all three backends, and with the unpatched b92daa350 on KVM, the clone's restore fails at the same refusal.
• Not run locally: the VMM tests. The management RPC refuses aggregates, so no VMM test reaches this path; NVX's scenario covers it through the CLI.

[github-actions]

⚠️ Unsafe Code Detected

This PR modifies files containing unsafe Rust code. Extra scrutiny is required during review.

For more on why we check whole files, instead of just diffs, check out the Rustonomicon