What is VxM (and what it isn't)

Overview

VxM is a specialized hypervisor orchestration utility designed exclusively for Nitrux. It enables multi-GPU workstations to run the host (Nitrux) and a guest (e.g., Windows 11) simultaneously, with each OS having exclusive control over its own dedicated graphics card.

Unlike traditional virtualization solutions that rely on emulated graphics or translation layers (which introduce significant latency), VxM leverages VFIO PCI passthrough to provide the guest OS with direct, bare-metal access to hardware resources. This architecture eliminates virtualization overhead for graphics and input, making the guest indistinguishable from a natively installed OS.

graph TD
    subgraph Hardware ["Workstation Hardware"]
        iGPU["Primary GPU (Intel/AMD)"]
        dGPU["Secondary GPU (Nvidia/AMD)"]
        Input["Keyboard & Mouse"]
    end

    subgraph Host ["Host: Nitrux OS"]
        Orchestrator["VxM Orchestrator"]
        Hyprland -->|Uses| iGPU
    end

    subgraph Virtualization ["Virtualization Layer"]
        QEMU["QEMU / KVM process"]
        InputLinux["Input-Linux (Evdev Passthrough)"]
    end

    subgraph Guest ["Guest: Windows 11"]
        Game["Games / Apps"]
        Driver["Native GPU Driver"]
    end

    %% Connections
    Input -->|Default| Hyprland
    Input -.->|Ctrl+Ctrl Toggle| InputLinux
    InputLinux -->|Injects| Guest
    
    Orchestrator -->|Manages| QEMU
    QEMU -->|VFIO Passthrough| dGPU
    Driver -->|Direct Access| dGPU
    
    %% Styling
    style dGPU fill:#f96,stroke:#333,stroke-width:2px
    style Guest fill:#bfb,stroke:#333,stroke-width:2px
    style Host fill:#bbf,stroke:#333,stroke-width:2px

Loading

1. Key Features

VxM automates the complex "choreography" required for hardware passthrough, which is typically done manually via shell scripts or complex libvirt XML edits.

• Zero-latency input: Implements a software-based KVM using input-linux.

• Dynamic driver isolation: Automatically unbinds the secondary GPU from the host driver (e.g., amdgpu or nvidia) and binds it to vfio-pci on demand. It safely rebinds the device to the host when the VM shuts down.

• DDC/CI display automation: Eliminates the need to switch monitor inputs manually. VxM sends DDC commands to your monitor to physically switch inputs (e.g., from DisplayPort to HDMI) when the guest starts and stops.

• Rootless execution model: Runs the QEMU process as an unprivileged user while handling privileged hardware preparation (hugepages reservation, device ownership) securely in the background.

• "Batteries included" approach: Automatically manages swtpm for TPM 2.0 emulation and heuristically detects the correct OVMF (UEFI) firmware pairs, ensuring compatibility with modern Windows security requirements out of the box.

2. What is VxM?

• A hardware orchestrator: It is primarily a tool for managing hardware resources (GPUs, input devices, monitors) and assigning them to a virtual machine.

• Built by and for Nitrux: We build VxM to integrate with Nitrux's immutable root architecture, overlay system, and security model.

• A "Dual-Boot" killer: We design it for users who need to run high-performance workloads (gaming, CAD, Adobe Suite) in a secondary OS without rebooting their machine.

3. What VxM isn't?

• Not a general-purpose VM manager: It is not a replacement for VirtualBox, GNOME Boxes, or virt-manager. We did not design it for running server clusters, headless instances, or software-rendered VMs.

• Not for single-GPU systems: VxM strictly requires at least two GPUs (e.g., an iGPU for the host and a dGPU for the guest). It does not support single-GPU passthrough scenarios.

• Not an emulation layer: It does not translate graphics calls (like VirGL or Venus). If you do not have a secondary GPU to pass through, VxM will not function.

• A closed or proprietary software or a cross-distro utility. While VxM is designed specifically for Nitrux and doesn't aim for compatibility with other distributions (even if its building blocks do), it remains fully open-source. PRs are welcome.

• Not a container, runtime, Live USB creator, Linux distro, desktop environment, or—for the record—proprietary software.

Note

We don't know why anyone would think that, but one can never know, so let's clarify.