A brief experiment comparing graphics on native qemu-kvm vs libvirt. I tried to make them as close to similar in operation as possible. Here's the relevant flags:

* qemu-kvm -device virtio-gpu -vga none -display "sdl,gl=on"
* virt-install --graphics spice,gl.enable=yes,listen=none

Result:
- qemu's sdl display is pretty fast, supports resizing/scaling in a way that the guest vm will detect.
- libvirt and virt-install's method requires a separate viewer tool, virt-viewer, which is ... *extremely* laggy and much lower-than-acceptable framerate, even local-only enabled by 'listen=none'

I dunno. I don't enjoy qemu's endless number of flags, but I'm not enjoying libvirt either as it doesn't seem to simplify anything and makes performance worse.

(If you know a better graphics configuration for libvirt/virt-install, please let me know)

@whack IIRC virt-install doesn't provide great defaults for all the very useful libvirt options. I do love the whole tooling stack though so don't give up yet.

Try a manual install with virt-manager or even better gnome-boxes to get the right XML. Then use virsh edit to see it and use the snippets that work best.

I can give you access to a vmhost to play with if that would help.

Lastly my mgmtconfig project builds great XML when you use the virt resource, but I didn't optimize everywhere yet.

@purpleidea imo the libvirt docs are ... not good. There's a lot of docs, but all the stuff I find is endless manpage reference-like material and nothing about how the tools fit together.

I may abandon this exploration as I'm mostly-happy with qemu. virt-builder and virt-install are appealing because they can help automate some machine setup, but I'm already doing that with cloud-init on qemu. virt-builder *might* be a shortcut to support other distros that don't ship cloud-init images, though! I'll keep poking.

Here's the stuff I'm fiddling with:
https://github.com/jordansissel/experiments/tree/master/qemu

Main entry is 'fun.sh' which orchestrates building the disk image (w/ qemu + cloud-init) and running the vm. 'distros.rb' is just code to generate cloud-init for specific configurations.

I won't mind using libvirt if I can stop banging my head against its weirdness, otherwise I'll just stick with qemu directly.

experiments/qemu at master · jordansissel/experiments

random experiments. Contribute to jordansissel/experiments development by creating an account on GitHub.

GitHub

@whack Virt-builder and it's author Rich are both brilliant. If you're just interested in a single occasional vm, you can get by with qemu, but if you want more serious stuff, libvirt wins my heart. Lots of docs here too (see tools on the right) https://libguestfs.org/

Mgmt res examples: https://github.com/purpleidea/mgmt/blob/master/examples/lang/virt1.mcl and https://github.com/purpleidea/mgmt/blob/master/examples/lang/virt-builder.mcl

and there's a sadly still undocumented virtualization "module" which does the right glue everywhere: https://github.com/purpleidea/mgmt/blob/master/modules/virtualization/main.mcl

I can patch with graphical too.

libguestfs, library for accessing and modifying VM disk images

libguestfs, library and tools for accessing and modifying VM disk images

@purpleidea I went pretty deep into the weeds injecting packages and scripts into upstream OS images with guestfish/etc before deciding that I went a bit too far off of the beaten path lol

The VMs in this scope are going to be for automated testing; so in effect, they'll be short-lived and throw-away like docker containers. I'll probably have some tooling automatically build all the images frequently so I have a fresh set of disk images to test with on the latest releases. If I get along well enough with virt-builder, I'll experiment with mgmtconfig for operating it <3

@whack The docs in mgmtconfig are ... not good. My infinite apologies here. I'm trying my best but am resource strapped. 😅 I am doing my best to improve as fast as I can and happy to help fill in the blanks and put in some work to help you build something if it's not obvious or if you hit any issues.

Friends suggest I AI generate some docs, but I've held back for now.

Mgmt is definitely the tool if you want to build large distributed systems and test them. I need to do more of that myself too!

@purpleidea "The docs in mgmtconfig are ... not good."

Ahem.

The docs in mgmtconfig are ... a work in progress!

<3

@purpleidea Ok I gave virt-builder a shot and despite my vast and well-documented history of causing computers to explode on first-contact, I was successful getting virt-builder to make me a fedora-43 image with some extra packages. Hell yes! This is substantially better than the limited availability of cloud-init images.

@purpleidea

Heck yeah: "Resources run simultaneously instead of waiting for non-dependent resources" -- awww yeah I'm stoked to absolutely wreck this workstation (honestly, in a good way)

I also see that virt:builder copies mgmt into the vm image -- if I can get this going, I'll see about replacing my firstboot commands with another mgmt run or something like that.

Kinda cool? Again, not having a bad time!

@whack Yeah! You get all the magic of concurrency and utilization of large core count machines, without needing to know very much about concurrency.

Indeed mgmt can take over and continue the setup! Part of my thesis is that provisioning, configuration management, orchestration and a few more aspects can all be modelled with the same tool and language.

For a long time I was focused on research. Recently I'm focused on polish, bug squashing, and performance.

@purpleidea "apologies for the docs!" .... my friend, I am currently scouring your user guide, your resource reference, function reference, extensive examples in yaml and mcl...

You may not apologize! This is quite good!

@whack You are an excellent human, and far too kind. If you've got good "Puppet" knowledge, and put in the work to squint, then you can fumble around. But there still a lot of blanks that need filling in and documenting.

We're on the matrix home server in #mgmtconfig if you want to ask longer questions too.

@purpleidea If I can ever find a matrix app that works on Fedora without crashing, I'll join lol.

Knowing puppet *definitely* helps, though I'm still exploring how the graph relationships affect event signals -- like how a timer could trigger an exec (I found a yaml example, but not an mcl example, etc)

@whack The yaml is really just the legacy pre-compiler frontend, you should focus on mcl.

I use fractal on Fedora without issues. https://flathub.org/en/apps/org.gnome.Fractal

In that old timer example, it's not so much triggering the exec, but rather blocking the exec resource from running due to graph dependency edges... When timer is "fulfilled" the concurrent resource execution then focuses on exec and it runs on its own.

Install Fractal on Linux | Flathub

Chat on Matrix

@purpleidea Oh that makes more sense now. (after some more reading, I think I really would use watchcmd/watchfiles for my experiment here)