On Wednesday, January 12, 2022, <[email protected]> wrote:
On Tue, 11 Jan 2022 22:26:51 +0300 Andrew Randrianasulu <[email protected]> wrote:
On Tuesday, January 11, 2022, Andrew Randrianasulu <[email protected]> wrote:
On Tuesday, January 11, 2022, <[email protected]> wrote:
On Tue, 11 Jan 2022 18:46:59 +0300 Andrew Randrianasulu <[email protected]> wrote:
<snip>
> I think you already using system mode (full system emulation > - so you can run NetBsd or MacOS or windows - they see > emulated/virtual machine to run on..) User-mode qemu run > Linux binaries on top of same kernel BUT they can belong to > another architecture! So overhead can be less.. (no mmu > emulation). You can edit files inside proot 'vm' from host - > no need for samba/nfs.
I have macOS in user mode, it runs fine (but need to re-install). It also ran fine in system mode (since deleted). I have not checked if there is a speed difference between the two nodes, nothing very noticable anyway.
I think your terminology on system/user modes a bit different from assumed by qemu?
Can you try to explain what you mean by those two modes in your own words/experience?
In virt-manager you can have two kinds of VMs: QEMU/KVM and QEMU/KVM User Session. The first is referred to as "system", the second as "session". The default on Fedora_35 is (user) session, where qemu runs under the user's profile. If you use virsh to e.g. edit the VM's config you can type e.g. "virsh edit Debian11_aarch64" . If you want to use a VM under system, you have to type "virsh --connect qemu:///system edit Debian11_aarch64". The VMs have a different domain specified in the XML that defines a VM. user mode has domain "qemu", system mode domain "kvm". I noticed that whereas in user (session) mode you can define pretty much any hardware for the VM, in system mode some things are not available, like PCIe controllers.
https://wiki.libvirt.org/page/FAQ#What_is_the_difference_ between_qemu:.2F.2F.2Fsystem_and_qemu:.2F.2F.2Fsession.3F_ Which_one_should_I_use.3F
==== What is the difference between qemu:///system and qemu:///session? Which one should I use? All 'system' URIs (be it qemu, lxc, uml, ...) connect to the libvirtd daemon running as root which is launched at system startup. Virtual machines created and run using 'system' are usually launched as root, unless configured otherwise (for example in /etc/libvirt/qemu.conf).
All 'session' URIs launch a libvirtd instance as your local user, and all VMs are run with local user permissions.
You will definitely want to use qemu:///system if your VMs are acting as servers. VM autostart on host boot only works for 'system', and the root libvirtd instance has necessary permissions to use proper networkings via bridges or virtual networks. qemu:///system is generally what tools like virt-manager default to.
Not anymore. virsh default is session (user), virt-manager shows whatever VMs are existing, in two list depending on the connection.
good to know, in case someone will need this info!
qemu:///session has a serious drawback: since the libvirtd instance does not have sufficient privileges, the only out of the box network option is qemu's usermode networking, which has nonobvious limitations, so its usage is discouraged. More info on qemu networking options: http://people.gnome.org/~markmc/qemu-networking.html
This networking info is out-of-date, at least for Fedora_35. The Fedora default setup already creates a bridge device, which is needed for user mode networking. It simply worked out of the box, even a network install where the booted system is at a minimum. On none of the three VMs I created so far was networking a problem. I don't remember if the first instance on install was NAT or bridge.
good!
The benefit of qemu:///session is that permission issues vanish: disk images can easily be stored in $HOME, serial PTYs are owned by the user, etc.
What is a problem is file sharing, cut-and-paste, audio. Not of course for real hardware, but would be nice-to-have for the VMs. On Fedora_35, you get either frequent SELinux errors (some of which you can negate), or the solutions found on the web simple don't work, presumable because their qemu was much older.
well, hopefully we can troubleshut them one by one. Just on new email thread.
====
well... this is something virt-manager specific as I guessed.. all qemu modes likely run qemu-system-* under the hood (but uml is user-mode linux and lxc is container... mode. non-system, as far as guest kernel not needed for them... if I recall things correctly!). you can check with top while vm is running...
virt-manager is a GUI front-end for libvirt, which is what really interfaces to a VM. Multiple VM types are supported by libvirt, like XEN and QEMU, but virt-manager is much more limited .
You'll find many instructions to use virsh or cmd line to configure qemu. Very uncomfortable compared to virt-manager, which is more like VirtualBox in this respect, although I use virsh as well, but only if I cannot get a new VM install going using virt-manager.
Indeed all qemu emulations are called qemu-system-xxxx . When a system emulation is installed (like aarch64) then virt-manager puts it in the list of options for the architecture of a new VM. I have X86_64, armhf, and aarch64 at the moment.
I found two papers/slideshows describing qemu-system vs qemu-user back in qemu-0.12.5 days proot + qemu-user was like 2x-4x faster than qemu-system (compilers tend to use integer arithmetic units, not fpu/simd). But since those days qemu in general improved and some devices now virtualized (less overhead) https://web.archive.org/web/20111119183403if_/http://adt.cs.upb.de:80/quf/qu... https://web.archive.org/web/20150301073841if_/http://adt.cs.upb.de:80/quf/qu... (see p. 48)
My new CPU arrived, and I see a big increase in speed. 2400G versus 5700G: 4 minute 1080p30 video render with default settings: 32.5 fps -> 78 fps (no hardware support). But CPU was never 100%, 80% was peak, obviously there are some non-CPU limits there). It could be it is faster on Mint 20.2 where I can use vaapi for rendering (Fedora does not seem to support that).
it should - one more item to troubleshoot.. Compile CinGG after "make new" 12 minutes -> 4 minutes (just enough
time to make myself a new coffee...)
3x faster! nice
Boot Debian_11_aarch64 until login screen: 86 secs -> 55 secs. Login until desktop ready (CPU load drops stark): 68 secs -> 38 secs. If feels much more responsive too.
cool! I was afraid new cpu might be delayed into infinity due to electroncs components shortages/delays...
Regrettable, I don't think building on aarch64 will be much faster (will time it): virt-manager does not allow more than 8 vCPUs to that VM, maybe it is architecture dependent. However, in many places there are single threaded pieces in the build, they will definitely speed up because the turbo is 30% higher, and there are more instructions per clock.
I hope cooling part (fan assembly) and PSU/motherboard will handle this well.. good luck with new machine!
MatN