<br><br>On Tuesday, January 11, 2022, Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com">randrianasulu@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>On Tuesday, January 11, 2022,  <<a href="mailto:mnieuw@zap.a2000.nl" target="_blank">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 18:46:59 +0300<br>
Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com" target="_blank">randrianasulu@gmail.com</a>> wrote:<br>
<br>
<snip><br>
> > > I think you already using system mode (full system emulation - so<br>
> > > you can run NetBsd or MacOS or windows - they see emulated/virtual<br>
> > > machine to run on..) User-mode qemu run Linux binaries on top of<br>
> > > same kernel BUT they can belong to another architecture! So<br>
> > > overhead can be less.. (no mmu emulation). You can edit files<br>
> > > inside proot 'vm' from host - no need for samba/nfs.  <br>
> ><br>
> > I have macOS in user mode, it runs fine (but need to re-install). It<br>
> > also ran fine in system mode (since deleted). I have not checked if<br>
> > there is a speed difference between the two nodes, nothing very<br>
> > noticable anyway.  <br>
> <br>
> <br>
> I think your terminology on system/user modes a bit different from<br>
> assumed by qemu?<br>
> <br>
> Can you try to explain what you mean by those two modes in your own<br>
> words/experience?<br>
<br>
In virt-manager you can have two kinds of VMs: QEMU/KVM and QEMU/KVM<br>
User Session. The first is referred to as "system", the second as<br>
"session". The default on Fedora_35 is (user) session, where qemu runs<br>
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 Debian11_aarch64" .<br>
If you want to use a VM under system, you have to type "virsh --connect<br>
qemu:///system edit Debian11_aarch64".<br>
The VMs have a different domain specified in the XML that defines a VM.<br>
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.</blockquote></blockquote><div><br></div><div><br></div><div><br></div><div><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">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</a></div><div><br></div><div>====</div><div>What is the difference between qemu:///system and qemu:///session? Which one should I use?</div><div>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).</div><div><br></div><div>All 'session' URIs launch a libvirtd instance as your local user, and all VMs are run with local user permissions.</div><div><br></div><div>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.</div><div><br></div><div>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: <a href="http://people.gnome.org/~markmc/qemu-networking.html">http://people.gnome.org/~markmc/qemu-networking.html</a></div><div><br></div><div>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.</div><div><br></div><div>====</div><div><br></div><div>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... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>ah, thanks... so, this is virt-manager specific terminology.. </div><div><br></div><div>I was referring to other method of qemu use, one where you call qemu-user-something and not qemu-system-something. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
MatN<br>
</blockquote>
</blockquote>