On Tue, 11 Jan 2022 22:26:51 +0300
Andrew Randrianasulu <randrianasulu@gmail.com> wrote:

> On Tuesday, January 11, 2022, Andrew Randrianasulu
> <randrianasulu@gmail.com> wrote:
>
> >
> >
> > On Tuesday, January 11, 2022, <mnieuw@zap.a2000.nl> wrote:
> > 
> >> On Tue, 11 Jan 2022 18:46:59 +0300
> >> Andrew Randrianasulu <randrianasulu@gmail.com> 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.

> 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.

>
> 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... 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.

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).

Compile CinGG after "make new" 12 minutes -> 4 minutes (just enough
time to make myself a new coffee...)

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.

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.

MatN