Page MenuHomeFreeBSD

vmm: Add a device file interface for creating and destroying VMs
ClosedPublic

Authored by markj on Oct 9 2024, 9:20 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Nov 26, 7:24 AM
Unknown Object (File)
Sat, Nov 23, 4:01 AM
Unknown Object (File)
Fri, Nov 22, 3:40 PM
Unknown Object (File)
Thu, Nov 21, 11:23 PM
Unknown Object (File)
Sat, Nov 16, 3:39 AM
Unknown Object (File)
Sat, Nov 16, 1:31 AM
Unknown Object (File)
Tue, Nov 12, 1:48 PM
Unknown Object (File)
Mon, Nov 11, 1:30 AM

Details

Summary

This supersedes the sysctl interface, which has the limitations of being
root-only and not supporting automatic resource destruction, i.e., we
cannot easily destroy VMs automatically when bhyve terminates.

For now, two ioctls are implemented VMMCTL_VM_CREATE and
VMMCTL_VM_DESTROY. Eventually I would like to support tying a VM's
lifetime to that of the descriptor, so that it is automatically
destroyed when the descriptor is closed. However, this will require
some work in bhyve: when the guest wants to reboot, bhyve exits with a
status that indicates that it is to be restarted. This is incompatible
with the idea of tying a VM's lifetime to that of a descriptor, since we
want to avoid creating and destroying a VM across each reboot (as this
involves freeing all of the guest memory, among other things). One
possible design would be to decompose bhyve into two processes, a parent
which handles reboots, and a child which runs in capability mode and
handles guest execution.

In any case, this gets us closer to addressing the shortcomings
mentioned above.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Oct 9 2024, 9:20 PM
This revision is now accepted and ready to land.Oct 21 2024, 3:26 PM

Would it make sense to use an nvlist (and avoid the reserved array)?

Would it make sense to use an nvlist (and avoid the reserved array)?

At this point, not particularly. I don't foresee this interface growing a lot of functionality, since VM configuration is generally done using a set of follow-up ioctls. The reserved fields are there just in case, as they're basically free.

Maybe someday it'd be nice to have an nvlist-based interface, but it's easy to switch to that later.

Historically I had wanted the 'maxcpus' tunable to be one of the possible settings at creation time (and an nvlist is how I would have passed in such settings). However, I think I've mostly made that requirement OBE in practice.