Show HN: VM-curator – a TUI alternative to libvirt and virt-manager(github.com)
github.com
Show HN: VM-curator – a TUI alternative to libvirt and virt-manager
https://github.com/mroboff/vm-curator
11 comments
From https://news.ycombinator.com/item?id=46433355 re: quickemu, LXD snapshots and live migration, virtio-gpu-rutabaga:
> IOMMU GPU passthrough with device selection would be a helpful feature: https://www.google.com/search?q=gpu+passthrough+qemu
rutabaga_gfx does GPU paravirtualization: https://github.com/magma-gpu/rutabaga_gfx
> IOMMU GPU passthrough with device selection would be a helpful feature: https://www.google.com/search?q=gpu+passthrough+qemu
rutabaga_gfx does GPU paravirtualization: https://github.com/magma-gpu/rutabaga_gfx
IOMMU pass-through is the next feature I'm working on, but I felt it was now time to release the V1. Currently, vm-curator supports:
- VM creation with over 100 different OS profiles, built for KVM and emulation - 3D para-virtualization support using virtio-vga-gl (virgl) - UEFI and TPM support (auto-configured for OSes that need it, like Windows 11) - QCOWS2 Snapshot support. - USB Pass-through support and management.
There is also a rich metadata library with ascii art, descriptions of OSes, and fun-facts.
VM Creation with IOMMU will require the following for GPU pass-through: - a motherboard capable of proper IOMMU support. - 2+ GPUs, plus a dummy HDMI or DP1.4 plug for the passed-through GPU - Looking-Glass for display
VM-curator can host and manage other gpu-passthrough configurations, as the application supports editing each VM's launch script, but the above profile is what I'm planning to put into the creator system.
I have a TRX40 (Threadripper) motherboard, which will serve as an ample test-bed, but I still need to acquire a second GPU.
- VM creation with over 100 different OS profiles, built for KVM and emulation - 3D para-virtualization support using virtio-vga-gl (virgl) - UEFI and TPM support (auto-configured for OSes that need it, like Windows 11) - QCOWS2 Snapshot support. - USB Pass-through support and management.
There is also a rich metadata library with ascii art, descriptions of OSes, and fun-facts.
VM Creation with IOMMU will require the following for GPU pass-through: - a motherboard capable of proper IOMMU support. - 2+ GPUs, plus a dummy HDMI or DP1.4 plug for the passed-through GPU - Looking-Glass for display
VM-curator can host and manage other gpu-passthrough configurations, as the application supports editing each VM's launch script, but the above profile is what I'm planning to put into the creator system.
I have a TRX40 (Threadripper) motherboard, which will serve as an ample test-bed, but I still need to acquire a second GPU.
Btw, this feature is now available in v0.2.x! vm-curator supports single-gpu passthrough (tested locally,) and multi-gpu pass-through via looking-glass (experimental: needs testing.)
single-gpu-passthrough relies on a script (run outside the app) to disconnect the GPU from the current X.org or Wayland session and then to attach it to the running VM. When the VM is shut down, the script runs this process in reverse. This means you can only run one VM at a time with your main display and peripherals, and while you're running that VM, you can't access your host with your display and peripherals (you can always SSH into it while the VM is running.)
This is the common process for getting single-GPU-passthrough to work. vm-curator helps prepare the system and generates the scripts automatically.
multi-gpu-passthrough is designed to run with looking-glass, but it can also support physical KVM switching if the user prefers.
single-gpu-passthrough relies on a script (run outside the app) to disconnect the GPU from the current X.org or Wayland session and then to attach it to the running VM. When the VM is shut down, the script runs this process in reverse. This means you can only run one VM at a time with your main display and peripherals, and while you're running that VM, you can't access your host with your display and peripherals (you can always SSH into it while the VM is running.)
This is the common process for getting single-GPU-passthrough to work. vm-curator helps prepare the system and generates the scripts automatically.
multi-gpu-passthrough is designed to run with looking-glass, but it can also support physical KVM switching if the user prefers.
Systems with iGPU (CPU RAM) + dGPU (dedicated GPU RAM) support GPU passthrough IIUC.
With the proprietary Nvidia Linux module,
These environment variables cause processes to run on an Nvidia dGPU instead of the iGPU: https://download.nvidia.com/XFree86/Linux-x86_64/435.17/READ... :
Bazzite has supergfxctl and the Nvidia modules installed in their OCI system images ("Native Containers"; ublue-os)
IIRC from (awhile ago) trying to run a Windows VM with GPU passthrough to the dGPU, a device selection gui would've helped
Arch wiki > Supergfxctl > 5.1 Using supergfxctl for GPU passthrough (VFIO) https://wiki.archlinux.org/title/Supergfxctl#Using_supergfxc...
Linux for ROG notebooks > VFIO dGPU Passthrough Guide > VM Creation Walkthrough: https://asus-linux.org/guides/vfio-guide/#vm-creation-walkth... ;
> After running this, the terminal will display a list of all your PCI devices, listed by their IOMMU group. Skim through the list until you find the IOMMU group that contains your dGPU.
But then under "selinux considerations" it says: https://asus-linux.org/guides/vfio-guide/#selinux-considerat... :
> /etc/libvirt/qemu.conf and find this line:
With the proprietary Nvidia Linux module,
These environment variables cause processes to run on an Nvidia dGPU instead of the iGPU: https://download.nvidia.com/XFree86/Linux-x86_64/435.17/READ... :
__NV_PRIME_RENDER_OFFLOAD=1 \
__GLX_VENDOR_LIBRARY_NAME=nvidia \
process-to-run-on-dGPU;
Bazzite has supergfxctl and the Nvidia modules installed in their OCI system images ("Native Containers"; ublue-os)
IIRC from (awhile ago) trying to run a Windows VM with GPU passthrough to the dGPU, a device selection gui would've helped
Arch wiki > Supergfxctl > 5.1 Using supergfxctl for GPU passthrough (VFIO) https://wiki.archlinux.org/title/Supergfxctl#Using_supergfxc...
Linux for ROG notebooks > VFIO dGPU Passthrough Guide > VM Creation Walkthrough: https://asus-linux.org/guides/vfio-guide/#vm-creation-walkth... ;
> After running this, the terminal will display a list of all your PCI devices, listed by their IOMMU group. Skim through the list until you find the IOMMU group that contains your dGPU.
But then under "selinux considerations" it says: https://asus-linux.org/guides/vfio-guide/#selinux-considerat... :
> /etc/libvirt/qemu.conf and find this line:
#security_default_confined = 1I look forward to testing this out. I keep a windows VM mostly for updating hardware when there's no other way. USB passthrough is a feature that doesn't always work in a stable manner with libvirt.
Update: Released first bug-fixes (v 0.1.1). Notable fixes include:
- Defaulting to SGL display-mode when enabling 3D accel for Linux VMs for better graphics performance. - Changing display mode for existing VMs is now available in Manage - Adding multiple VMs for the same OS is now supported - Custom VM naming now persists. - Renaming VMs is now supported.
Next major feature: Full PCI passthrough support, including GPU passthrough via looking-glass.
- Defaulting to SGL display-mode when enabling 3D accel for Linux VMs for better graphics performance. - Changing display mode for existing VMs is now available in Manage - Adding multiple VMs for the same OS is now supported - Custom VM naming now persists. - Renaming VMs is now supported.
Next major feature: Full PCI passthrough support, including GPU passthrough via looking-glass.
How is this possible? I remember reading something about 3D para-virtualization not being supported on NVIDIA consumer GPUs.
I think you’re referring to the ability to split a physical NVIDIA GPU into multiple virtual GPUs so that you can do full GPU pass-through with one card (without having to resort to hacks like disconnecting host sessions.)
What vm-curator provides is an easy way to use QEMU”s built in para-virtualization (virtio-vga-gl, a.k.a. virgl) in a manner that works with NVIDIA cards. This is not possible using libvirt based tools because of a bug between libvirt and NVIDIA’s Linux drivers.
What vm-curator provides is an easy way to use QEMU”s built in para-virtualization (virtio-vga-gl, a.k.a. virgl) in a manner that works with NVIDIA cards. This is not possible using libvirt based tools because of a bug between libvirt and NVIDIA’s Linux drivers.
Does it fetch the hardrive inages for all these preconfigured ones from somewhere? That would be a huge timesaver.
No. I thought about that, but decided it would be too much of a hassle to maintain, plus it becomes legally problematic with non-FOSS, non-abandonware profiles (i.e. modern Windows and MacOS.)
Instead, for many profiles, it provides a link to the OS’s website (or archive.org) where you can download the installation media.
Instead, for many profiles, it provides a link to the OS’s website (or archive.org) where you can download the installation media.
I see...
To be fair the archive.org links probably does not change much
To be fair the archive.org links probably does not change much
Behold, vm-curator! A fast and friendly VM management TUI written in Rust. You can create, configure, organize, and manage VMs directly with QEMU. No libvert. No XML. No wonky UI's. Just the right level of friendliness, customization, and speed to be really really useful.
The best part? 3D para-virtualization works with NVIDIA cards (via virtio-vga-gl!) No jumping through hoops to get GPU passthrough working!
(Disclaimer: This works great with other guest Linux VMs, but is not suitable for Windows gaming. If you want to game on Windows within a VM, passthrough is a must. vm-curator will have fast and friendly support soon.)
Looking for contributors (especially to help with the ascii art,) and donations are welcome. (Claude was a big help, but this was not a vibe-coded affair. We pair-programmed approx. 10,000 lines of code here. It was a great way to learn Rust, actually!)