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