Comment by _joel
2 years ago
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.
2 years ago
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.
virt-manager is one of the most underrated softwares there is. It's a powerhouse and I use it all the time. It is going to expect you to know some basic terminology about VMs, but it reminds me a lot of the old skool GUIs that were packed with features and power.
If your needs are simple or you're less technical with the VMs, Gnome Boxes uses the same backend and has a beautiful streamlined GUI. With the simplicity of course comes less flexibility, but cool thing is you can actually open Gnome Boxes VMs with virt-manager should you later need to tweak a setting that isn't exposed through Boxes.
I’m so appreciative that virt-manager has a GUI that crafts and then lets you edit the XML directly. It really eased that beginner into competent stages of using the program for me.
Agreed, it's much better than nothing, though I still don't know how to port forward.
Absolutely love virt-manager. I try gnome-boxes every so often and it just doesn’t compare. I guess its interface is easier for beginners.
I know it's not the same thing, but Quickemu happily works over SSH too.
Run it on a remote system via ssh, and it will "X-Forward" the Qemu console on my local Wayland session in Fedora.
First time I ran it, thinking I was doing a headless mode, and it popped up a window, was quite surprising. :)
It's wild how important and useful a program that does nothing but configuration can be.
Imagine what life would be like if configuration was separated from the software it configures. You could choose your favorite configuration manager, and use that, rather than learn how each and every program with a UI reinvented the wheel.
The closest thing we have are text configuration files. Every program that uses them has to choose a specific language, and a specific place to save its configs.
An idea I've been playing with a lot lately is a configuration intermediary. Use whatever language/format you want for the user-facing config UI, and use that data as a single source of truth to generate the software-facing config files.
You have some incumbent competition already, in case you're not aware, and I'd say many of these are closer to what you're describing than text configuration files.
You would do well to learn by past and current attempts. This book should be enlightenig (and yes, Elektra is very much alive): https://www.libelektra.org/ftp/elektra/publications/raab2017...
Would also be a useful excercice to write a new configuration UI for existing configuration backend(s) (preferably something already in use by some software you're already in want of better configuration for) - even if you do end up aiming at your own standard (xkcd.com/927), it should give you some clarity on ways to approach it.
The irony here is that the problem you have proposed - the complexity introduced by creating a new solution - is the same problem that each solution is intended to solve.
That means that any adequate solution should recursively resolve the problem it introduces.
oh, and also thank you for introducing me to Elektra. That was very helpful of you.
Libvirt and virt-manager are just simplified user interface to the real software, which is qemu(and KVM). They solve pretty trivial problems, like parsing config file and passing the right options to the qemu binary.
Yes, they have some additional useful administration features like start/stop based on a config file, serial console access, but these are really simple to implement in your own shell scripts. Storage handling in libvirt is horrible, verbose, complex, yet it can't even work with thin LVs or ZFS properly.
Unless you just want to run stuff the standard corporate way and do not care about learning fundamental software like qemu and shell, or require some obscure feature of libvirt, I recommend using qemu on KVM directly, using your own scripts. You'll learn more about qemu and less about underwhelming Python wrappers, and you'll have more control on your systems.
Also, IBM/Red Hat seems to have deprecated virt-manager in favour (of course) a new web interface (Copilot).
Quickemu seems to be of more interest, as it allows launching new VM right after a quick look at examples, without time wasting on learning a big complicated UI.
The real advantage to libvirt is that it also works with things other than qemu.
Who uses libvirt with anything else than qemu? Xen has its own much better UI tools, like the xl toolstack, or xcp-ng with Xen orchestra.
If you mean libvirt can provide single UI to different hypervisors, that is true, but I don't see any technical reason to have single UI to different hypervisors. It just provide familiar clicky UI for nontechnical users who do not want to bother with learning hypervisor features and its dedicated tools.
> Quickemu seems to be of more interest, as it allows launching new VM right after a quick look at examples, without time wasting on learning a big complicated UI.
Why would anyone want a qt frontend when you can call a cli wrapper, or better yet the core binary directly?
Libvirt can dump configs as scripts. If virsh/virt-manager does the 90% of the tedious work with a fine UI in order to be replicated later, I guess libvirt wins here.
You've missed the point of libvirtd.
That's possible, but you also seem to have missed mine, which is libvirt is not great time investment if you want to learn how qemu works, or have the most flexibility and control in its deployment.
I just like passing in options to QEMU on cmdline. This works well for some older OS like Windows NT on MIPS, or Ultrix.
This is the way.
Anyone running virt-manager on mac connecting to a headless linux hypervisor on the same network? I tried installing it through "brew", but was getting many random errors.
I thought about running it over the network using XQuartz, but I'm not sure how maintained / well supported that is anymore.
In virt-manager, you should* be able to go to file -> add connection.
Select Hypervisor "Custom URL", and enter: qemu+ssh://root@<host>/system
And Bob's your uncle.
It works great for me! This means it likely won't work for you until you've paid the proper penance to the computer god.
This might not fit your use case but what I do is:
ssh -L 5901:localhost:5901 username@hypervisor
on the hypervisor, start Qemu with -vnc :1
Then open a local VNC client like RealVNC and connect to localhost:1
I've done this several years ago, with no issues, though I haven't tried any time recently.
I just wish it had a web interface option, but I guess there is always proxmox.
Or if you're feeling a little more adventurous https://github.com/retspen/webvirtcloud
Cockpit has a good web interface for libvirt
Virt Manager is fantastic. I've used it for more than a decade and it's been rock solid throughout.
Being able to connect to my TrueNAS Scale server and run VMs across the network is the icing on the cake.
At this point, you could probably use Qubes OS, which is basically an OS that runs everything in VMs with a great interface. My daily driver, can't recommend it enough.
I wish Quickemu would make it easier to interface with libvirt, but apparently that's been marked as out of scope for the project.
I've been using proxmox to manage my containers and vms.
Do people normally move from virt-manager to proxmox or the opposite?