virt-manager VS gamescope

It's still being updated. I don't see anything on the virt-manager homepage or GitHub that would suggest it is deprecated.

https://virt-manager.org/

https://github.com/virt-manager/virt-manager

It can't do literally everything Qemu/libvirt can do using only the UI, but given that it has escape hatches to directly edit libvirt configurations, and libvirt has escape hatches to directly pass arguments to Qemu, there's very little you can't do with it.

I would love to see a serious comparison (features & performance) between VMWare ESXi, Proxmox VE and let's say a more stock RHEL or Ubuntu. And maybe even include FreeBSD/bhyve.

Because yes, in terms of core functionality it should be in the same ballpark. And in terms of UI, Virtual Machine Manager [0] was not that bad.

[0] https://virt-manager.org/

Shout out to https://virt-manager.org/ - works much better for me, supports running qemu on remote systems via ssh. I used to use this all the time for managing bunches of disparate vm hosts and local vms.

If not, I would just run a CentOS Stream 8 virtual machine using either GNOME Boxes or virt-manager, and set up networking and ssh so you can access the database from the host.

https://virt-manager.org/ <- Recommend this as Front-end

I'd say it is half-baked webmin. You can only use it with NetworkManager, and if you have an even remotely complex network setup for VMs, NetworkManager usually must be turned off, which makes Cockpit practically unusable. virt-manager [1] is way more powerful for those who like managing VMs with GUI.

[1] https://virt-manager.org/

$ apt build-dep libvirt $ git clone https://github.com/libvirt/libvirt.git Cloning into 'libvirt'... $ cd libvirt $ meson setup build $ ninja -C build $ ninja -C build install $ which virsh /usr/local/bin/virsh $ which libvirtd /usr/local/sbin/libvirtd $ apt install libgtk-3-dev libpulse-dev libgbm-dev libspice-protocol-dev \ libspice-server-dev libusb-1.0-0-dev libepoxy-dev libfdt-dev $ git clone -b v5.1.0 http://git.qemu.org/qemu.git $ cd qemu-v5.1.0 $ git submodule add -f https://git.kernel.org/pub/scm/utils/dtc/dtc.git dtc $ ./configure --disable-werror --target-list=arm-softmmu \ --enable-opengl --enable-gtk --enable-kvm --enable-guest-agent \ --enable-spice --audio-drv-list="oss pa" --enable-libusb \ --enable-trace-backend=simple --enable-debug $ make $ make install $ git clone https://github.com/virt-manager/virt-manager.git $ apt install gobject-introspection libosinfo-1.0-0 libosinfo-1.0-dev \ gir1.2-libosinfo-1.0 libvirt-glib-1.0-dev $ cd virt-manager $ ./setup.py configure --prefix=/usr/local $ sudo ./setup.py install $ sudo usermod -a -G libvirt root $ sudo usermod -a -G libvirtd root $ sudo usermod -a -G libvirt-qemu libvirt-qemu $ sudo usermod -a -G libvirt marietto $ sudo adduser libvirt-qemu $ sudo groupadd --system libvirt $ sudo groupadd --system libvirt-qemu $ sudo newgrp libvirt-qemu $ newgrp libvirt $ /usr/local/sbin# libvirtd & [1] 2875 $ /usr/local/sbin# virtqemud & info : libvirt version: 9.7.0 info : hostname: chromarietto error : virPidFileAcquirePathFull:409 Failed to acquire pid file : /var/local/run/libvirt/qemu/driver.pid Resource temporarily unavailable error : virStateInitialize:672 : Initialization of QEMU state driver failed Failed to acquire pid file : /var/local/run/libvirt/qemu/driver.pid Resource temporarily unavailable error : daemonRunStateInit:617 : Driver state initialization failed $ /usr/local/sbin# ps ax | grep libvirt 2875 pts/0 Sl 0:00 libvirtd $ /usr/local/sbin# ps ax | grep virtqemu nothing If I do the opposite way : $ /usr/local/sbin# virtqemud & $ /usr/local/sbin# ps ax | grep virtqemu 3041 pts/0 Sl 0:00 virtqemud $ /usr/local/sbin# libvirtd & info : libvirt version: 9.7.0 info : hostname: chromarietto error : virPidFileAcquirePathFull:409 Failed to acquire pid file : /var/local/run/libvirt/qemu/driver.pid Resource temporarily unavailable virStateInitialize:672 : Initialization of QEMU state driver failed Failed to acquire pid file : /var/local/run/libvirt/qemu/driver.pid Resource temporarily unavailable daemon RunStateInit:617 : Driver state initialization failed $ /usr/local/sbin# ps ax | grep virtqemu 3041 pts/0 Sl 0:00 virtqemud $ /usr/local/sbin# ps ax | grep libvirt nothing

I want to test Hyprland with NixOS in a VM using Virt-Manager (https://virt-manager.org/) on Arch Linux host before installing it on my machine.

I think your information is quite outdated. The HWC overlay planes are heavily used, you can see this trivially just doing a 'dumpsys SurfaceFlinger' or grabbing a systrace/perfetto trace. When it falls back to GPU composition it's very obvious as there's a significant hit to latency and more GPU contention.

The overlay capabilities of the modern Snapdragons are also quite absurd. They support like upwards of a dozen overlays now and even have FP16 extended sRGB support. Some HWCs (like the one in the steam deck) even have per plane 3D LUTs for HDR tone mapping (ex https://github.com/ValveSoftware/gamescope/blob/master/src/d... )

The composition is bandwidth heavy of course, but for static scenes there's a cache after the HWC in the form of panel self refresh.

One of the unfortunate things about Wayland is every compositor will have its own quality of implementation affecting things like latency.

With XOrg, especially in the pre-compositing days, you could choose whatever WM you want and it wouldn't have any impact on the rendering performance of X clients. Once the Composite extension was added and everyone started running composited X desktops, that started to change, and the increased latency already started appearing - in an arguably worse architecture than Wayland because there were often three processes involved with lots of IPC per draw: X-Client->X-Server->X-Compositor->X-Server->CRTC. At least in Wayland it's more like Wayland-Client->Wayland-Compositor->CRTC.

If you're unhappy with the rendering latency of your Wayland sessions, it may be worth trying alternative compositors... they likely vary significantly. The Valve/Steam folks have made a minimal one specifically optimized for games/low-latency [0]. I doubt the SteamDeck would be seeing as much success as it is if Wayland were so problematic in this department.

[0]: https://github.com/ValveSoftware/gamescope

Use gamescope.

While streaming from the Deck to another device (phone with Steam Link app or another PC running steam), taking a screenshot on the Deck (hold the steam or ... button, and press R1) crashes the session (https://github.com/ValveSoftware/gamescope/issues/961). This one also impacts Decky Recorder. If you're recording the screen or have replay mode on and take a screenshot, you'll have a crash.

Mangohud (GOverlay), libstrangle, gamescope. Pick your poison.

Hey folks. I've got a 11900H motherboard and use the iGPU and stock Intel graphics drivers that I keep current. Even at baseline (so without overclocking of any kind, with good Corsair memory sticks configured without XMP and regardless of voltage), I would be able to use Windows 11 and the CMD or Terminal programs without issue but after some time they would be corrupt and unreadable. The fix was in Terminal, go into Settings, then Render, and turn on Software Rendering. I hope this helps someone else. FYI the corruption was very much like other Intel UHD graphics samples reported in this link: https://github.com/ValveSoftware/gamescope/issues/356