Repository navigation
vm: inspect builds its device, disk, fs and balloon views from one vm.info - #327
Merged
Merged
Conversation
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
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.
vm inspecton a running CH VM called vm.info four times: FsList, DeviceList and DiskList each went throughlistWith, and BalloonStatus did a fourth, with five record loads among them. This PR addshypervisor.RunningViewer: oneRunningVMClient(a single record load) and one vm.info, from which the fs, vfio, disk and balloon views are all built with the extractors the list methods already use. Inspect uses it when the backend implements it; Firecracker keeps the old path.Behavior is the same whenever vm.info succeeds. When it fails, the old path dropped each block separately; the new path drops them together and logs one warning.
Measured on test2 (1 vCPU / 1 GiB guest, NUMA-pinned slice), interleaved ABBA, 8 rounds x 4 blocks x 30 calls:
That is -7.4% (Mann-Whitney p<0.0001), measured against master with an extra record load in the PR arm that this version no longer makes, and every block of the PR arm was faster than every block of master. strace showed 4 api.sock connects on master and 1 here. The inspect JSON was byte-identical between arms (1580 B, balloon block included).
The same measurement also tried reusing the boot poll's vm.info in direct-boot start (3 vm.info calls down to 2). That gave +0.02% (p=0.98), so it is left out.
Gates:
make lint(0 issues on linux and darwin),make fmt-check,asl,go build ./...on both GOOS, andgo test -race ./cmd/... ./hypervisor/...on darwin and in a Linux arm64 container.