Add Virtualization/KVM interface

[locnnil]

Description

Adds a virtualization interface (name still TBD) that lets a workshop launch hardware-accelerated (KVM) virtual machines from inside its container, without requiring the workshop itself to run as a VM.

The system SDK gains a single virtualization slot; any regular SDK can declare a matching virtualization plug. When plug and slot are connected, these host character devices are passed through as LXD unix-char devices:

• /dev/kvm
• /dev/vhost-net
• /dev/vhost-vsock
• /dev/vsock

They are group-owned by the workshop user, mode 0660, so no world access is granted. /dev/net/tun is not passed through because LXD already provides it in the container. Devices absent on the host (e.g. vsock modules not loaded) are marked required: false and do not block launch.

The interface follows the existing device-interface pattern (gpu, camera): a type=none config device carries the serialized config, round-tripped by LxdToSdkProfile. It is not auto-connected (deny-auto-connection: true) because it grants privileged access to host virtualization devices; it must be connected manually via workshop connect command.

Self-review quick check

• Make decisions that cost a lot to reverse explicit in the PR description.
• Avoid nested conditions.
• Delete dead code and redundant comments.
• Normalise symmetries by sticking to doing identical things identically.

// one way to handle errors
if err := f(); err != nil {
   ...
}

// one way to handle multiple returns
val, err := f()
if err != nil {
   ...
}
...

• Check that coupled code elements, files, and directories are adjacent. For example, test data is stored as close as possible to a test.
• Put variable declaration and initialisation together.
• Divide large expressions into digestable and self-explanatory ones. Use multiple variables if required.
• Put a blank line between two logically different chunks of code.
• Follow the style guide for new error messages.

Docs

Procedure:

• I have checked and added or updated relevant documentation.
• [ ] I have checked and added or updated relevant release notes.
• I have included the technical author in the review.

Content:

• Headings and titles accurately describe the content.
• New and updated pages include correct metadata.
• Documentation tests are added or updated where applicable (for tutorial/ and how-to/ sections).
• Documentation follows the style guide.
• If needed, docs/.coverage.yaml updated, coverage tags added (.. artefact).

---

Or:

• I confirm the PR has no implications for documentation.

[akcano]

Docs LGTM, with a few minor fixes.

[jonathan-conder]

I want to understand more about the security implications of this. If it's unsafe to connect the interface when the container runs untrusted code (i.e. agents), we should at least document that. We should try to prevent local privilege escalation for the host user.

I found some related info here but haven't looked too deeply yet: containerd/containerd#7442.