Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

OpenVMM: support sandbox blocks, networking, and supplied RAM in the microVM management RPC

Open
  • Is something wrong?
#760 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
grpc, linux, python
Domain
api, backend, networking

Research direction

Read the control frontends design linked in the issue, then inspect the management RPC protocol and server handling for DevicesConfig, MicrovmSnapshotConfig, MemoryConfig, and VirtioFs. Compare those settings and validation rules with the command-line options for sandbox blocks, networking, RAM backing files, and aggregate filesystems. Done means the acceptance tests cover capture and restore in both directions and the gRPC reference documents the new fields.

Written by the indexing model from the issue text.

Description

The management RPC, OpenVMM's TTRPC and gRPC vmservice endpoint, has created, captured, and restored microVMs since 7ec02fec6, but only for part of the machine that the command line supports. A microVM with sandbox blocks or a network device, one with a caller-supplied RAM backing file, or one that shares an aggregate host filesystem can only be launched, captured, and restored from the command line. The design describes both frontends as equivalent; see 5.2.1 Control Frontends. Except for the control console, these limits come from missing protocol fields and server handling, not from a design constraint.

Missing in the management RPC

  • Sandbox blocks. DevicesConfig has no field for the fixed-role microVM blocks, and its former virtio_blk field is reserved. MicrovmSnapshotConfig has no snapshot tier, block identity mode, storage generation, or scratch restore mode. Restore rejects these snapshots with "TTRPC restore does not support microVM sandbox-block snapshots".
  • Network device. Creation accepts only the fixed virtio-fs and virtio-console devices, so a request cannot configure the microVM NIC or its network profile, egress and ingress policy, host-loopback access, proxy, or forwards. Restore rejects network attachments with "ttrpc restore does not yet expose microVM network attachments".
  • Supplied RAM backing file. MemoryConfig has no backing-file field, so the server always creates the RAM file itself. The command line also accepts --memory file=PATH, which capture publishes by copying.
  • Host filesystem policy. VirtioFs carries one directory with one access mode. Aggregate shares, file children, allowed, denied, and writable paths, and caller ownership are command-line only, and restore rejects an aggregate with "ttrpc restore does not expose an aggregate microVM filesystem".

Out of scope

  • Control console. 7ec02fec6 rejects it deliberately, because the management endpoint cannot provide an authenticated broker attachment. Supporting it needs a separate design for delivering the control capability.

Acceptance

  • The protocol carries every launch, capture, and restore setting that the command line accepts for these devices, and the server validates them with the command line's rules instead of a second copy.
  • VMM tests capture and restore over TTRPC with sandbox blocks for each snapshot tier, with a network device, with a supplied RAM backing file, and with an aggregate host filesystem.
  • A snapshot captured over the RPC restores from the command line, and the reverse.
  • The gRPC reference describes the new fields.
Dominant language
Python
Stars
408
Forks
28
Avg merge
16h 20m
Merged PRs (30d)
355

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/nvx

All issues in microsoft/nvx

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.