I think most of your issues are equating "QEMU == vmware player" or something like this. It's really not: as a matter of fact, QEMU is just a processor emulator

I think most of your issues are equating "QEMU == vmware player" or something like this. It's really not: as a matter of fact, QEMU is just a processor emulator, in software. It's not a full-operating-system VM environment at all and can be (and is) used for things like running a single binary without virtualization. Why is this confusing? What you're really looking for is KVM, which -is- a hypervisor that uses the processor's virtualization instructions to implement a complete virtual machine. And then QEMU has a backend, for x86/x86_64, that uses KVM to accelerate its processor virtualization (and I believe some hardware support as well). Using KVM through QEMU at least gives you a command line interface to do things instead of "write a C program to talk to the kernel API", but this is still far from the level of a tool that a desktop user would want to use. QEMU+KVM is basically at the level of one of the random barely-documented executables that you'd see in the installation of a VM software package. So what should you use here? The next layer up is libvirt, which provides a system-level daemon to talk to (so you're not just running an emulator from a terminal that exits when you close the terminal) and a command shell & configuration files for defining machines, networks, storage, and so on. Still not a great UX, but at least now you're at the level of being able to define and run a machine. Many users are going to manage these things through a wizard-based or graphical workflow instead of a CLI, so there's applications like Boxes that's built into GNOME (https://wiki.gnome.org/Apps/Boxes https://wiki.gnome.org/Apps/Boxes) or virt-manager (https://virt-manager.org/ https://virt-manager.org/) which is desktop-agnostic. Both of these also help with establishing a graphical interface to the virtual machine itself, if necessary.