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/quf11/quf2011_13.pdf https://web.archive.org/web/20150301073841if_/http://adt.cs.upb.de:80/quf/quf2011_proceedings.pdf (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 >
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
