QEMU with VirtIO GPU Vulkan Support(gist.github.com) |
QEMU with VirtIO GPU Vulkan Support(gist.github.com) |
Graphical interfaces like virt-manager are nice at first, but I don't need an abstraction on top of multiple hypervisors to make them all look superficially the same, because they're not. Eventually the abstraction breaks down and gets in the way.
I need the ability to use the full capability of QEMU. I'll write a shell script to manage the complexity of the arguments. At least I don't have to deal with XML, validation, and struggling with enabling the options I want that are only supported by one specific emulator, which libvirt doesn't support, because it's not common to all of the backends.
I like it that libvirt integrates with firewalld. libvirt via virt-manager also provides you with quick options for dns.
My fear is that this would be a lot of wrangling with qemu before I get there. I am not fond of virt-manager, the UI is clunky, but for setting up a machine it is really helpful.
Personally I'm very lazy, so I just make a virtual bridge and force QEMU to use it for everything; putting all my VMs on my local network.
I totally understand that not everyone can do this, which is why I asked the question, I'd be interested in exploring how you would prefer the network topology to look like.
Having a virtual network on a machine would mean having a dns/dhcp server (I think dnsmasq can actually do both by itself) for ease of use, but I think I could give you a 5 line bash script that could do basically what you want easily, depending on what it is you want.
The normal "internal" network topology ends up giving you an outbound NAT to the local network (to, eventually, get onto the internet) which, I personally really dislike.
I would've gone and bought Intel ARC dGPUs for my Proxmox cluster if they supported hardware virtualization on their consumer line.
Here's a project that, iirc, backported and made a DKMS for from Intel's tree: https://github.com/strongtz/i915-sriov-dkms
I also recall from that time that Intel had SR-IOV code for the iGPU (and I think their dGPUs) in the new Xe driver
Edit: Can't substantiate further, but this is what Huang Rui, the prior steward of the Venus patchset, said: https://lore.kernel.org/all/20240411102002.240536-1-dmitry.o...
Edit 2: For further clarity, Virtio-GPU Native Context would permit running the native GPU drivers (with some modifications, minimal is what I remember being claimed) inside a VM
I have even used it in Windows to make a legacy proprietary OpenGL application work properly with recent Windows versions + a mobile (now unsupported) AMD GPU.
I tried to highly restrict my virtual machine with just an allow list (works via firewalld), and at the same time allowing the vm to query the (physical) LAN for dns-sd.
Tbh, I could not get the latter to work directly. I ended up letting my host function as an dns-sd reflector.
> virtual bridge
Does that work with wlan? libvirt creates a bridge, but with or without NAT it could not let the vm participate like a normal LAN-client. I thought it was a limitation of wireless lan bridging.
Using virsh, you can dump the default network with net-dumpxml, which is the default bridge libvirt creates, modify it and create another network. Add the modified file with net-create (non-persistent) or net-define.
This way the VMs can participate in the LAN and, at the same time, the LAN can see your VMs. Works with wifi and doesn't depend on having workarounds for bridging wifi and ethernet. Debian has a wiki entry on how to bridge with a wireless nic [0] but I don't think it's worth the trouble.
[0] https://wiki.debian.org/BridgeNetworkConnections#Bridging_wi...
But why do you duplicate the default bridge? Wouldn't adding a route in the router + default bridge be enough for this setup to work?
https://github.com/openzfs/zfs/releases/tag/zfs-2.2.6
Edit: changed sentence to make more sense
Edit 2: And if we are to interpret stable as in Linux LTS, then that would be 6.12 which is supported by 2.2.7 as you said
Non-LTS kernels very frequently go EOL before OpenZFS supports them, or there is only a very brief window that there is support for a non-EOL kernel.
In practice, it's hard to use a non-LTS kernel with openzfs for any significant duration.
What stable means in this case is subject to individual use cases. In my case, I don't find having to wait a bit for ZFS to catch up despite being on an EOL kernel to be catastrophic, but after having some time to think, I can see why someone would need an LTS kernel.
This impacts distributions like NixOS in particular, which have a strict policy of removing EOL kernels.