[WIP] tests/update_eve_image: kvm↔k cross-HV conversion test suite - #1203
Closed
eriknordmark wants to merge 11 commits into
Closed
[WIP] tests/update_eve_image: kvm↔k cross-HV conversion test suite#1203eriknordmark wants to merge 11 commits into
eriknordmark wants to merge 11 commits into
Conversation
Three eden escripts for the EVE-kvm to EVE-k cross-flavor BaseOs upgrade, registered in the suite: a base upgrade check, a ContentTree blob-reuse check (zero bytes re-downloaded after the switch), and an app+volume recreate check that also survives a controller reboot. The app is deployed as soon as the new-flavor rootfs is running, before the cluster is fully up, so the run exercises the device-side volumemgr park-and-retry instead of masking the longhorn/CDI readiness race. Signed-off-by: eriknordmark <erik@zededa.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Escripts driving the EVE-kvm to EVE-k boot-disk conversion without a geometry change: the base conversion round-trip and a conversion-refused negative case, plus prep-kvm-to-k-topology.sh, which builds the single-disk ZFS-on-boot persist pool the installer would. Run manually (not registered in CI) since they need purpose-built EVE images. Signed-off-by: eriknordmark <erik@zededa.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The resize (shrink+grow) and grow-only escripts that drive the actual small->large GPT repartition. They assert the partitions grew, the device passed through the converting state, blobs were reused across the conversion, and the TPM-sealed vault stayed locally unlocked across the geometry change. Includes the two READMEs describing the multi-image bringup. Run manually with a TPM-enabled bringup. Signed-off-by: eriknordmark <erik@zededa.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Escript that migrates a deployed app's qcow2 volume to a Longhorn PVC across the kvm->k conversion (ext4), asserting the app and its written data marker survive the conversion with no image re-download. Run manually. Signed-off-by: eriknordmark <erik@zededa.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A new 'eden controller edge-node add-wireless' command injects a WiFi device port into the device config with its credentials encrypted (ECDH) against the device certificate, so EVE decrypts them at device-config ingest. This exercises credential decryption independent of the app pipeline and of physical radio presence. The encryption is factored out of the app-userdata path as a reusable EncryptForDevice helper (hard error, no plaintext fallback). Since the QEMU device model has no radio, the command synthesizes a wireless PhysicalIO and a non-management SystemAdapter; verified in a sandbox that nim decrypts the credentials at ingest even with no radio present. Signed-off-by: eriknordmark <erik@zededa.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Merged
6 tasks
eriknordmark
force-pushed
the
f9-run
branch
2 times, most recently
from
July 3, 2026 17:42
9c3329e to
e077084
Compare
Add the F9 fault-case escript: force a /persist wipe and verify the device-identity and connectivity-critical files survive via the /config backup + early-boot restore, recovering the device with no controller reachable. It injects a controller-encrypted WiFi device port before the backup so, after the wipe, nim re-decrypts the credentials offline from the restored ecdh cert -- one CipherBlockStatus check proving identity restore, config restore, and decrypt from restored key material. Depends on the add-wireless CLI (openevec PR). Run manually with RESIZE_EVE_VER set; not added to the auto-run test list. Signed-off-by: eriknordmark <erik@zededa.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
6 tasks
Add the F11 partial-corruption sibling of the F9 persist-loss test: instead of wiping /persist, truncate each backed-up critical file to about half its bytes -- except the two .bak files (checkpoint/lastconfig.bak and DevicePortConfigList/global.json.bak) -- then verify the device still recovers offline. On the next boot restore's needsRestore gate restores the files that are invalid for their type (certs *.pem lose -----END, *.json fail json.Valid) while keeping the no-validator checkpoint files, so lastconfig recovers via its intact .bak. controllercerts has neither a .bak nor a validator, so the test also surfaces whether a truncated controllercerts is recoverable offline. Drafted, not yet run; targets an image carrying the OnboardingStatus backup fix. Depends on the add-wireless CLI. Run manually with RESIZE_EVE_VER set. Signed-off-by: eriknordmark <erik@zededa.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a twodisk-ext4 case to prep-kvm-to-k-topology.sh so the kvm->k conversion suite can set up a device whose /persist is ext4 on a whole second disk (sdb), with the boot disk left with a free tail. The storage-resizer decides grow for this layout exactly as it does for the two-disk ZFS case (no P3 on the boot disk => shrink is not applicable => grow off the free tail), so it runs the existing update_eve_image_kvm_to_k escript with DISK_TOPOLOGY=two-disk EXPECT_DECISION=grow and the assert-grown-no-p3 geometry check, unchanged. Unlike the ZFS sibling this needs no in-guest pool creation and no vault fs->zvol migration on kvm->k, so the persist disk is built offline and sudo-free: a GPT partition named P3 plus mkfs.ext4 via -E offset on a sparse raw, converted to qcow2. The first boot still creates IMGB+P3 on the boot disk (storage-init only repartitions when both are absent), then persist is moved to sdb and the boot P3 deleted. Verified end-to-end on host eden 2026-07-07 (full conversion PASSED, TPM seal preserved, app running post-conversion). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: eriknordmark <erik@zededa.com>
Extend the app-volume-migration test to also migrate a CONTAINER app's data volume, alongside the existing VM app. It deploys eclient with a pre-formatted ext4 data volume (built host-side by gen-data-volume.sh) mounted at /data, writes a marker into it before the kvm->k conversion, and asserts the marker survives without recreate afterwards. Because EVE-k (kubevirt) does not auto-mount a container's data volume at its MountDir — it presents it as a raw block device (lf-edge/eve#6145) — the post-conversion verify mounts the migrated volume by its block device and reads the marker there, so the test exercises the migration invariant independent of that auto-mount gap. Also adds ctr-marker.sh and parameterizes wait-for-app-running.sh to take an app name. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: eriknordmark <erik@zededa.com>
eriknordmark
changed the title
Add an opt-in RELOCATE_CRITICAL_HIGH knob to the kvm->k resize escript. When set, fill-persist.sh forces the identity/connectivity-critical files (storage-resizer's defaultBackupPatterns) into high blocks at peak fill, so the offline resize2fs shrink must relocate them and a watchdog-interrupted move can corrupt one, exercising the /config backup+restore fail-safe end-to-end rather than only hitting throwaway fill chunks. A small file cannot simply be rewritten in place: ext4's allocator is goal-based and keeps the copy in the file's original (low) block group. Instead, write a large temp file, which cannot fit the packed low region and so allocates in the high free tail; sync to commit that allocation; copy the content in place; then truncate back to the real size so the surviving head block stays high. The sync is required -- truncating before it lets delayed allocation place only the final small size, back low. Off by default so the single-run shakedown stays deterministic; the multi-day soak turns it on. The deterministic restore coverage in the F9 (full wipe) and F11 (truncate) tests is unchanged; this is the probabilistic real-resize complement. Signed-off-by: eriknordmark <erik@zededa.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add ESP-B partition geometry assertions to the kvm->k conversion escripts (the resize, grow, and refused variants), so the second EFI System Partition is verified across the conversion. Signed-off-by: eriknordmark <erik@zededa.com>
Contributor
Author
|
Superseded by #1209, which folds this branch's tests into a single branch ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
WIP: the EVE-kvm ↔ EVE-k cross-HV conversion test suite for
tests/update_eve_image, driven end-to-end through the controller. This branchstacks the following (oldest → newest):
container app's data volume survive the conversion without recreate
its data intact. Verify reads the marker from the migrated block device, because
EVE-k (kubevirt) does not auto-mount a container's data volume at its
MountDir(raw block device) — tracked as HV=k: container app data volumes not mounted at MountDir when the app has no cloud-init user-data eve#6145.
Disk-topology setup for the repartition / two-disk / ZFS cases is
prep-kvm-to-k-topology.sh(ext4-shrink,ext4-grow,twodisk-zfs,twodisk-ext4,ext4-toofull,zfs-grow/zfs-notail).Builds on #1196 (cross-HV suite). References lf-edge/eve#6145.