runtime: Refactor factory/hypervisor save/restore paths for clearer s…#458
Draft
Camelron wants to merge 4 commits into
Conversation
Add support for VM Template factory on the clh path.
In order to support snapshot/restore-based VM templating,
the following changes were needed:
1. For clh.go, implement SaveVM, PauseVM, restoreVM, ResumeVM
2. Remove initrd config check for VM Templating path. The
root disk image (when using image mode) is created in memory
and therefore captured in the VM snapshot.
3. Truncate the memory file to the size of the VM at factory VM
create time. This allows CLH to use the memory file
as the backing for the template VM memory, allowing O(1)
snapshot times.
4. CLH uses memory zones as backing for its memory on the template paths
5. Update StartVM in CLH to use the restore path when template is
configured and available
Signed-off-by: Cameron Baird <cameronbaird@microsoft.com>
Add k8s-vm-templating-test.bats which exercises pod create with the factory initialized on the target node. Signed-off-by: Cameron Baird <cameronbaird@microsoft.com>
The behavior we had before was that, for a starting k8s pod, it sees enable_template=true and therefore: 1. Tries NewFactory with fetchOnly=true 2. When that fails (because template.Fetch fails to find the artifacts, we retry with fetchOnly=false. This creates a direct factory which creates the template from scratch (hence we pay a full pod sandbox boot time here) and then restores from that. Hence the boot times are strictly worse on this path. Now, even when enable_template=true, we don't try to force a direct factory. Instead we just revert to the standard sandbox boot path. Signed-off-by: Cameron Baird <cameronbaird@microsoft.com>
…eparation wip commit message
Camelron
force-pushed
the
cameronbaird/upstream/runtime-go-clh-templating-rearchitect
branch
from
d775385 to
a910ff5
Compare
Camelron
force-pushed
the
cameronbaird/upstream/runtime-go-clh-templating
branch
8 times, most recently
from
02c125e to
96f2eaa
Compare
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.
DRAFT PR for comparison with current working branch upstream cameronbaird/upstream/runtime-go-clh-templating
Remove from
HypervisorConfig:BootToBeTemplate boolBootFromTemplate boolDevicesStatePath string(QEMU-specific; snapshot dir now carries this)CheckTemplateConfig()validation methodRetain but repurpose:
MemoryPath string→ subsumed byFileBackedMemory.PathAdd to
HypervisorConfig:FileBackedMemory *FileBackedMemoryConfigOther files that reference
BootToBeTemplate/BootFromTemplateand need updating:factory/template/template_linux.go— sets the flags; rewrite to useFileBackedMemoryfactory/factory_linux.go— resets the flags; removepersist.go— serializes/deserializes the flags; updatevm.go— skips timestamp whenBootFromTemplate; replace with restore-aware checkhypervisor.go— field definitions +CheckTemplateConfig(); remove/replaceqemu_amd64.go— memory flag logic referencing template booleansThe template factory (
factory/template/template_linux.go) is the main consumer. It currently:BootToBeTemplate=true, callsCreateVM+StartVM+Pause+SaveBootFromTemplate=true, callsCreateVM+StartVM(which internally restores)After refactor:
FileBackedMemory = {Path: ..., Shared: true}, callsCreateVM+StartVM+PauseVM+SaveVM(templateDir)+ factory-sideshared→falsepatching (CLH) or no patching needed (QEMU)FileBackedMemory = {Path: ..., Shared: false}, callsCreateVM+RestoreVM(ctx, templateDir)+ResumeVM+ReseedRNG+SyncTimeSummary
The hypervisor provides three generic primitives:
SaveVM(dir),RestoreVM(ctx, dir),ResumeVM(ctx). The caller decides:FileBackedMemoryConfig)