qemu/kvm, user management, create, launch, create a bridge, use a bridge

Thanks to Jetchisel, Malcomlewis, Tsu2 and many others.

  1. General thoughts

For opensuse and all other distributions if you use qemu/kvm they assume that only an admin with root privileges manage vms with virt-manager and virsh. They don’t supply any doc about how to manage a vm as a user.

I want to use qemu/kvm and to manage my vm as a user.
I just want to manage vms as I manage them with Virtualbox.
I just want to manage a sole vm in my desktop not a farm of vms.
It is an android-x86 7.1-r5 installed in a vm. see https://android-x86.org

This doc assumes that with yast virtualization manager you have already installed kvm.
I use android-x86 7.1-r5 as an example. You must interpret this tuto for your own OS you installed in a vm.

  1. Creating a vm disk

use this script create a vm disk somewhere in your home.


#!/bin/bash

qemu-img create -f qcow2 android_x86_7.1-r5.img 16G


Where

“android_x86_7.1-r5” is the name I decided for the disk

“16G” is the size of the disk, here 16 GB

  1. Create a vm and install android-x86 7.1-r5

Use this script (I adapted the script supplied by malcom lewis. Perhaps there is some garbage to delete). This script launches the installation iso.


#!/bin/bash

qemu-system-x86_64 \
-enable-kvm \
-m 2048 \
-smp 2 \
-cpu host \
-device virtio-tablet-pci \
-device virtio-keyboard-pci \
-serial mon:stdio \
-boot menu=on \
-net nic \
-net user,hostfwd=tcp::5555-:22 \
-vga qxl \
-hda ~/<path to>/android_x86_7.1-r5.img \
-cdrom ~/<path to>/android_x86/android-x86-7.1-r5.iso \

My adaptations :

“-vga qxl” instead of “-device virtio-vga,virgl=on”. Without this I get a black screen after the grub menu.

"-device virtio-tablet-pci " instead of “-device virtio-mouse-pci”. With this I get a seamless capture of the mouse cursor by the vm or the PC.

  1. Start a vm

use this script


#!/bin/bash

qemu-system-x86_64 \
-enable-kvm \
-m 2048 \
-smp 2 \
-cpu host \
-device virtio-tablet-pci \
-device virtio-keyboard-pci \
-serial mon:stdio \
-boot menu=on \
-net nic \
-net user,hostfwd=tcp::5555-:22 \
-vga qxl \
-hda ~/<path to>/android_x86_7.1-r5.img \

  1. Some notes

At this step we get a working vm.
This vm uses nat networking and there is no problem to use internet.
The vm is not a member of the LAN. It is masked inside the host. The IP address is something as 10.0.2.15. This is a problem for some app as kdeconnect. This app needs the vm is a member of the LAN or at least not masked.

  1. Create a vm using bridge networking (thus creating a bridge).

Importing the vm is a good thing because you will be able to make tests with your vm and understand all the components of your vm. This help to find the good settings for using your vm with qemu-kvm.

Import in virt-manager environment the vm.

For this in virt-manager add a new vm doing:

  • choose to import the existing image “~//android_x86_7.1-r5.img”. You need to add the folder containing the .img.

  • as OS indicate “android 7.1” then choose “Generic”

  • 2048 MB memory

  • 2 cpus

  • choose a name for the vm

  • check “custom settings”

  • choose for the network “:macvtap”, automatically “bridge” is set. Don’t touch this.

for example “eth0”

  • check your settings (memory, cpus, nic)

  • click on “begin the installation”

  1. Enabling the bridge

in main window of virt-manager

  • select the vm
  • in “edition” menu select “connection details”
    then “virtual networks”
    then “default”

check “autostart” “at boot”

check that “virbr0” the bridge is enabled. If not click on the arrow at the bottom left.

quit “connection details”

go to networkmanager. Ask for it to show virtual connections then you’ll see the “virbr0” connection.

in virt-manager select the vm and launch it.

you get now a vm using bridge networking and getting some IP address as 192.168.0.x

Now execute in a host console “ping 192.168.0.x”. You get some answers.

go to networkmanager. Ask for it to show virtual connections then you’ll see the “macvtap0” virtual connection.

The vm gets 192.168.0.x and your PC 192.168.0.y as IP address. It is the same LAN.

To establish an in-going connection to the host from the vm, perhaps you need to open a port in your host firewall.

Close the vm and quit virt-manager.

  1. using bridge networking with qemu-kvm (in our case qemu-system-x86_64)

At this step we get a bridge “virbr0” and we know it works well.

How to use it with qemu-kvm ?

Install tunctl

sudo zypper in tunctl bridge-utils

Give all the accesses for using the bridge to users:

  • in /etc/qemu/bridge.conf add the statement

allow virbr0

  • change the acl of bridge.conf

sudo chown root:kvm /etc/qemu/bridge.conf
sudo chmod 0660 /etc/qemu/bridge.conf

  • change the acl of qemu-bridge-helper

sudo chmod u+s /usr/lib/qemu-bridge-helper

  • i also read this somewhere but i don’t tried it because i found a solution and i am fed up with this problem:

sudo chown qemu:kvm /etc/qemu/bridge.conf
sudo chmod 0640 /etc/qemu/bridge.conf

  • with yast user manager

put your user-id to kvm group

  1. launching a vm using a bridge with qemu-kvm

use this script


#!/bin/bash

qemu-system-x86_64 \
-enable-kvm \
-m 2048 \
-smp 2 \
-cpu host \
-device virtio-tablet-pci \
-device virtio-keyboard-pci \
-serial mon:stdio \
-boot menu=on \
-net nic \
-net bridge,br=virbr0 \
-vga qxl \
-hda ~/<path to>/android_x86_7.1-r5.img \

You can check that the vm get 192.168.122.x and your PC 192.168.0.y as IP address. It is not the same LAN, but it is sufficient to establish connections. Again perhaps you need to open port at your host.

You can check in networkmanager there is a new virtual connection “tap0”.

I did not find a way for the vm to use the same dhcp server as the host one according to get an IP address as 192.168.0.x.

Before anything else,
I’d recommend dropping whatever you might be using as a reference or if you’re working without a reference, you’ll find it easier to use something like the openSUSE documentation as a guide.
The following is the link to the “single page” current openSUSE virtualization.
Read as much of the early chapters as you want, but it’s mostly foundation info for a technical deep dive.
You can skip those early chapters if you want and Just follow what is in the chapters I recommend
Unfortunately, it looks like the documentation’s organization has lost its way and looks like it’s written for an experienced Virtualization Administrator maybe coming from another distro and not for beginners.
I’d recommend beginners follows the documentation in the following order and focus on using the graphical tools, not the command line tools at all until you get a little experience and comfortableness using the GUI tools.

https://doc.opensuse.org/documentation/leap/virtualization/single-html/book.virt/
Chapter 5
Chapter 7
Chapter 12

When you’ve completed the above 3 chapters, then click the button to start your vm.

Some comment on what you’ve done:
If you installed KVM with libvirt using the YaST Virtualization Install module on your openSUSE HostOS,
You should have been offered the option to have the bridge device “br0” created for you and it would automatically be configured to enable any/all your Tuests to look like regular hosts on your physical network (in other words, don’t edit the configuration!).
Then,
When you configure your Guest’s network settings, you should not choose MacVtap (that’s useful if your HostOS connects to the LAN using a WiFi connection or need a non-virtual hardware networking solution, but let’s assume your HostOS is connecting using a wired, 802.3 connection and don’t have any special needs), you should instead select the regular ethernet connection and see br0 offered as an option. Of course, if you didn’t accept the option to have br0 created for you, you won’t find it.

That’s quite a few hoops you jumped through to configure a working Guest network connection, the MacVtap and tun network devices are normally used to create tunnel (aka vpn) endpoints and shouldn’t be used for what you’re doing.

I recommend creating an openSUSE Guest (actually practically any distro or even Windows will do) and use the graphical vm manager to configure and run.
If you have access to the Desktop on your HostOS and can run vm manager,
I recommend you just install, configure and run the machine with defaults first… The virtual machine should already be set up as a member of your LAN using the br0 network bridge.
Assuming it’s running properly, you’ll have something you can look at which is configured correctly and does what you want.

After you learn all you can about the running openSUSE VM,
Create a new Android VM and again accept the defaults, if the openSUSE ran without any tweaks, I’d expect your Android should set up and run the same way. If any tweaks were needed for the openSUSE instance, those same tweaks should probably be applied to your Android vm.

What I’m trying to say is that the things you’re doing should not be necessary and shouldn’t be done.
Installing, configuring and running a vm is really much easier and works properly without the complications you’re creating.

Lastly, it looks like the openSUSE virtualization documentation describes how to set up normal User access for managing libvirt managed virtual machines
But, I highly recommend don’t touch this part until you learn how to set up a basic vm first. Avoid unnecessary complications while you’re learning.

https://doc.opensuse.org/documentation/leap/virtualization/single-html/book.virt/#sec-libvirt-connect-connecting-dac

@tsu2

I must complete the definition of the problem.

I want automatically

  • at login, to launch the vm and to put it in the systray.
  • at logout or shutdown, to close the vm.

The solution I found is a login script and a logout script executed by plasma as user.

Is there another way than using qemu-kvm to do this as a user ?

Hello I made some cleaning in the scripts.

Script to create the vm


#!/bin/bash

qemu-system-x86_64 \
-enable-kvm \
-m 2048 \
-smp 2 \
-cpu host \
-vga qxl \
-device qemu-xhci \
-device usb-kbd \
-device usb-mouse \
-device usb-tablet \
-boot menu=on \
-net nic \
-net user \
-hda ~/<path to>/android_x86_7.1-r5.img \
-cdrom ~/<path to>/android_x86/android-x86-7.1-r5.iso \

script to launch the vm


#!/bin/bash

qemu-system-x86_64 \
-enable-kvm \
-m 2048 \
-smp 2 \
-cpu host \
-vga qxl \
-device qemu-xhci \
-device usb-kbd \
-device usb-mouse \
-device usb-tablet \
-boot menu=on \
-net nic \
-net user \
-hda ~/<path to>/android_x86_7.1-r5.img \

script to use the bridge “virbr0” and to get a vm not masked in the LAN thus you can establish connections with.


#!/bin/bash

qemu-system-x86_64 \
-enable-kvm \
-m 2048 \
-smp 2 \
-cpu host \
-vga qxl \
-device qemu-xhci \
-device usb-kbd \
-device usb-mouse \
-device usb-tablet \
-boot menu=on \
-net nic \
-net bridge,br=virbr0 \
-hda ~/<path to>/android_x86_7.1-r5.img \

some explanations.

“-vga qxl”

is today the default monitor for a vm

“-device qemu-xhci”

you need an usb controller where to connect your usb devices.
“qemu-xhci” is an usb controller compliant from usb 1 to usb 3

“-device usb-kbd”

if you have an usb keyboard

“-device usb-mouse”

if you have an usb mouse

“-device usb-tablet”

to get a seamless experience with the mouse cursor

“-net nic”

use a network adapter

“-net bridge,br=virbr0”

the network adapter is a bridge whose system name is “virbr0”

How to use a host bridge ?

  1. creating a bridge in our openSuse

via networkmanager plasma applet go to network settings.

At the bottom left click on the networkmanager settings icon.

Check “display virtual connections”

You must wait for a moment or quit networkmanager then go again to network settings.

At the bottom click on “+”

This time networkmanager offers to create virtual connections.

Choose “bridge”

I advise, according to be compliant with nmcli (online command of networkmanager) naming, to choose as friendly name (connection name) “bridge-brx” and system name (interface name, device name) “brx”, for example “bridge-br0” and “br0”.

Now you need to indicate what the actual OS connection the bridge must use also called the slave connection.

In tab “bridge” add an “ethernet” or “wifi” connection.

Rename it to a friendly name “bridge-brx-slave”, for example “bridge-br0-slave”

in the slave
in general settings" tab

  • check “automatically connect”
  • in “firewall zone” choose “internal”

in the bridge

  • in “firewall zone” choose “internal”

Why “internal” ? With this all vms using this bridge are member of the internal zone as the other PCs of your LAN. Thus, no need to open ports to establish connections.

You can’t start up the bridge with networkmanager because to start a bridge you start up the bridge slave and networkmanager does not offer to start up the slave.

I experiment that using nmcli to start up the slave is not clean.

You must restart your pc.

After the restart
in networkmanager you see

  • your ethernet connection (eth0) disconnected
  • your bridge “br0” connected

It seems networkmanager is a bit unmature about bridging.

If you use gkrellm you see

  • your ethernet connection (eth0) connected
  • your bridge “br0” connected
  1. Using the host brige

Now we can use this bridge with our vm.

Use this script to launch the vm and to use the bridge “br0”.


#!/bin/bash

qemu-system-x86_64 \
-enable-kvm \
-m 2048 \
-smp 2 \
-cpu host \
-vga qxl \
-device qemu-xhci \
-device usb-kbd \
-device usb-mouse \
-device usb-tablet \
-boot menu=on \
-net nic \
-net bridge,br=br0 \
-hda ~/QEMU_VM/android_x86_7.1-r5.img \

in networkmanager you see

  • your ethernet connection (eth0) disconnected
  • your bridge “br0” connected
  • a new connection “tap0”

If you use gkrellm you see

  • your ethernet connection (eth0) connected
  • your bridge “br0” connected
  • a new connection “tap0”

This time you can check that the vm gets an IP address like 192.68.0.x as the other PCs in the LAN. Thus, the vm is a member of the LAN.

This network bridging is a better way (secure and clean) than using “virbr0” a bridge created with virt-manager.
No need :

  • to add “allow virbr0” to bridge.conf
  • to change the acl of bridge.conf
  • to change the acl of “qemu-bridge-helper”
  • to be member of “kvm” group (i am not sure)

Enjoy !

Hello

You noticed there is no sound neither input nor output.

  1. in order to get sound output just add in the script

-device intel-hda

my motherboard gets a sound adapter “intel hda”

if you get crackly audio you must use the host pulseaudio server.

with yast software manager install the package “qemu-pa”

In the script add these statements

-audiodev pa,id=snd0,server=unix:/run/user/<userid>/pulse/native
-device hda-output,audiodev=snd0

<userid> is not your login id. It is your linux system id.

In a console type the command “id”. You get something like

uid=1000(<loginid>) gid=100(users) groupes=100(users),461(vboxusers),487(kvm)

then in my case the statement is

-audiodev pa,id=snd0,server=unix:/run/user/1000/pulse/native

  1. in order to get input sound

you can add an usb microphone.

For this add this statement in the script

-device usb-host,vendorid=<hex number>,productid=<hex number>

To find the vendorid and productid, type in a console the command “lsusb”

In my case i get this

x@grognon:~> lsusb
Bus 002 Device 002: ID 0bda:0321 Realtek Semiconductor Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 046d:08e5 Logitech, Inc.
Bus 001 Device 004: ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0
Bus 001 Device 003: ID 04d9:1702 Holtek Semiconductor, Inc. Keyboard LKS02
Bus 001 Device 002: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 006: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Find your microphone. The left hex number is the vendorid and the right hex number is the productid.

Be careful in qemu statement 046d becomes 0x046d. For example

-device usb-host,vendorid=0x046d,productid=0x08e5

you must add a dev rule in order the vm gets the right to use the microphone.

in /etc/udev/rules.d/

  • create a file 50.qemu.rules

in 50.qemu.rules

  • add the statement

<vendor name> <model name>

SUBSYSTEMS==“usb”, ATTRS{idVendor}=="<vendorid>", ATTRS{idProduct}=="<porductid>", GROUP=“kvm”, MODE=“0664”

This time copy the exact hex values supplied by lsusb.
for example

Logitech C920

SUBSYSTEMS==“usb”, ATTRS{idVendor}==“046d”, ATTRS{idProduct}==“08e5”, GROUP=“kvm”, MODE=“0664”

then refresh the dev rules.

sudo udevadm control --reload-rules
sudo udevadm trigger --attr-match=subsystem=usb

Also, you must be in the group “kvm”. Use the Yast user&group manager.

  1. the new script to launch the vm

#!/bin/bash

qemu-system-x86_64 \
-enable-kvm \
-m 2048 \
-smp 2 \
-cpu host \
-vga qxl \
-device usb-ehci \
-device usb-kbd \
-device usb-mouse \
-device usb-tablet \
-device usb-host,vendorid=<hex number>,productid=<hex number> \
-audiodev pa,id=snd0,server=unix:/run/user/<userid>/pulse/native \
-device intel-hda \
-device hda-output,audiodev=snd0 \
-boot menu=on \
-net nic \
-net bridge,br=br0 \
-hda ~/QEMU_VM/android_x86_7.1-r5.img \


Enjoy :slight_smile:

In the sound chapter made two errors

1 First one
.

  1. in order to get sound output just add in the script

-device intel-hda

my motherboard gets a sound adapter “intel hda”

must be

  1. in order to get sound output just add in the script

-soundhw hda

my motherboard gets a sound adapter “intel hda”

  1. Second one

In the script add these statements

-audiodev pa,id=snd0,server=unix:/run/user/<userid>/pulse/native
-device hda-output,audiodev=snd0

must be

In the script replace “soundhw hda” by these statements

-audiodev pa,id=snd0,server=unix:/run/user/<userid>/pulse/native
-device intel-hda
-device hda-output,audiodev=snd0

In the last script I supplied you can see I replaced “-device qemu-xhci” by “-device usb-ehci”.

I experimented a problem around setting the good speed when attaching my usb 2 webcam Logitech C920.

I confirmed this problem by googling around.

It seems that the qemu driver xhci manages badly the speed setting when attaching the usb 2 devices. Thus, xhci driver fails to attach the device.

ehci is compliant for usb 1 to usb 2.

It is strange because my mother board gets an usb 3 controller. Anyway this works well.

First, some opening comment…
I don’t know whether the @OP in this thread ever revealed what he’s using as his guide and reference, it might be important.
But, before posting to this thread again I decided I should review the content closely in the official openSUSE documentation and also the official documentation from the QEMU and Libvirt projects.
After all, it’s important to know what the highest authorities say on any particular subject, deviating from the best available advice is always at one’s own risk.
I also viewed the ArchWiki article on QEMU and Libvirt as well because I often find that whatever is there typically works fine on openSUSE, often with little or no modification for the differences between Arch and openSUSE, and its explanations are often easier to understand than original documentation.

And, it’s been awhile since I’ve researched this documentation deeply because for me, everything has “just worked” without having to open any documentation.
Unless I have time to burn for no reason, I don’t usually open up documentation when things already work.

What I found was this…
The use of a tap device attached to a bridge device is uniquely a QEMU procedure.
If you need to take advantage of special QEMU emulation, for example to emulate a specific device,
Then this is the right option.
But, compared to setting up networking as I described by simply specifying the use of a particular bridge device, this is unnecessarily complex and makes setting up every Guest a handcrafted nightmare because of things like colliding tap ids, colliding mac addresses if you don’t specify a static address or include code that dynamically generates an address, possibly more.
Every Guest and every network adapter has to be handcrafted and unique.

For 99% of all Users, and especially those who install virtualization using the YaST install virtualization module, you have a far better option that is simple and most importantly the configuration can be replicated to any number of Guests without any modification whatsoever.
Assuming you want networking to “just work” and don’t care what kind of network adapter is emulated as long as your Linux will identify and use it, the Libvirt procedure is what you want
Unlike QEMU where every Guest and network adapter used by a Guest has to be unique, the bridge device(which has the network type bridging/nat/hostonly built in) is a shared device where any number of Guests can simply connect to that bridge device for whatever type of network connection you want.

Side note on the difference between QEMU’s tap and bridge method vs Libvirt’s bridge device methods, offhand I can’t see any reason why QEMU can’t also connect the tap interface to whatever bridge device that is configured for a type of networking instead of configuring the networking separately and external to the bridge device (and in the case even setting up User Mode networking which although provides DNS and SAMBA services automatically, is a whole different networking approach)…

Now, a short comment on the openSUSE documentation which appears to be copied from SUSE documentation…
It’s poor. I could use very colorful language that’d be more accurate, but won’t here.
The following link is the openSUSE documentation for using virsh to configure your network connection, just a little more than a paragraph and I don’t know if I’d understand what is being done if I hadn’t read other documentation
https://doc.opensuse.org/documentation/leap/virtualization/single-html/book.virt/#virsh-network-devices
You’ll notice that immediately after the tiny section about connecting to the bridge device, it’s followed by the extensive explanation about using MacVtap to set up a tap interface with no indication that it’s a major departure and except in special situations like what I described in my prior post (real mode access to the network) to be avoided. BTW - during my documentation search I found some RHEL documentation which supports and describes using tap interfaces for the purposes I’ve described.

OK, now after pounding on our openSUSE documentation, here are the references to official documentation I do recommend for setting up networking by command line… And, of course you can look above and below the link’s location for “better” guidance creating, configuring and launching your Guest (plus other goodies)
First the Libvirt documentation and what 99% of all Users should set up
https://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29

Large parts of the openSUSE documentation for setting up a QEMU style networking follows, but you may want to follow the original documentation. This should not be used unless you have a special reason not to use the above libvirt mehod
https://qemu-project.gitlab.io/qemu/system/net.html
Besides the official documentation, the QEMU community wiki has some supplementary info
https://wiki.qemu.org/Documentation/Networking

On the subject of the microphone and any other USB devices,
Although it looks like by trial and error it’s been set up and working,
For anyone who wants to know how to do it without so much exploration,
Here is the ArchWiki article how to do a USB device pass-through which is good… Note that if you can use the graphical vm-manager at least for setup, it’s a lot easier to get your settings than querying for devices and searching for what you need in the results
https://wiki.archlinux.org/index.php/QEMU#Pass-through_host_USB_device

A side mention…
I came across an article (sorry lost the link) where the User did a pass-through of the GPU, when he did so it meant not just direct GPU hardware performance, it also meant that when he hooked up his monitor with an HDMI cable, he could also access mic and speakers through the monitor’s ports with superior performance compared to trying to pass the mic and speakers to the Guest. Remember that whenever you do a pass-through of anything, access to that device is monopolized by whatever is given access. Every other Guest and even the HostOS itself is blocked from accessing the device… which is a major reason why you will likely prefer shared objects whenever possible unless you’re trying to minimize or eliminate the milliseconds of latency associated with virtualizing access.

TSU

I made this tuto because :

  • there is no tool as Virtualbox to manage so easily a kvm machine with non root privileges.
  • there is no doc
    [li] (very poor doc about qemu also at qemu site) for non-techie persons.[/li]- the solutions I found are spread among internet and the time (2010-2020) and all comes from users who face to the same problems and supply a solution in various forums.

[li] I read official sites as Arch (the best for anything), Readhat, openSuse, Suse, Ubuntu, libvirt, qemu. All the docs are massively about using virt-manager and virsh. All these tools need root privileges. Some docs are old, others are recent.[/li]
When there is a doc about qemu it is very poor and techie and does not answer directly to the questions :

  • How to create a vm ?
  • How to start a vm at login and to stop cleanly a vm at logout or shutdown ?
  • how to get a vm which is a member of the lan ? [1]
  • how to share dynamically usb devices as microphone or web cam ? [2]
  • how to get input and ouput sound ?
  • how to use pulseaudio to get a good sound ?

All these things are so easy with Virtualbox.

[1] Tsu2 answers “use a host bridge” then I use a host bridge and i made a tuto about using a host bridge (see above).

[2] Malcom Lewis answers “there is only static sharing”. This is a serious drawback. I made a tuto about sharing an usb microphone in case it is not a problem.

If someone has a clean and secure solution to the questions, I am impatient to read him.

Some news from the sound front.

In case you get an usb webcam incuding a microphone. No need to add a second microphone for the guest.

Just replace


-device usb-host,vendorid=<hex number>,productid=<hex number> \
-audiodev pa,id=snd0,server=unix:/run/user/<userid>/pulse/native \
-device intel-hda \
-device hda-output,audiodev=snd0 \

by


-device intel-hda \
-device hda-output,audiodev=snd0 \
-device hda-micro,audiodev=snd0 \
-audiodev pa,id=snd0,server=unix:/run/user/<userid>/pulse/native \

“-audiodev pa,id=snd0,server=unix:/run/user//pulse/native”

This adds a pulseaudio sound adapter “snd0” to the vm

“-device hda-output,audiodev=snd0”

This connects the host speakers (in my case jack plug speakers) to the sound card "snd0"and share them dynamically with the host.

This connect the host microphone (in my case the webcam microphone) to the sound card "snd0"and share it dynamically with the host.

I get a jack plug microphone. This one is ignored.

I experimented by recording sound with an app in the guest and an app in the host. I can record sound with the two ones.

There is a plasma applet in the host systray saying “Qemu,Skype use the microphone”.

Then the new script to launch the vm is


#!/bin/bash

qemu-system-x86_64 \
-enable-kvm \
-m 2048 \
-smp 2 \
-cpu host \
-vga qxl \
-device usb-ehci \
-device usb-kbd \
-device usb-mouse \
-device usb-tablet \
-device intel-hda \
-device hda-output,audiodev=snd0 \
-device hda-micro,audiodev=snd0 \
-audiodev pa,id=snd0,server=unix:/run/user/<userid>/pulse/native \
-boot menu=on \
-net nic \
-net bridge,br=br0 \
-hda ~/QEMU_VM/android_x86_7.1-r5.img \

Enjoy :slight_smile:

When you don’t find something, a good question to ask before proceeding is “Why?”
Is it because your keyword search skills are faulty?
Is it because what you’re trying to find either does not exist or should not be done and if so, is there a good reason?

  1. Managing KVM, QEMU, Xen, and every other virtualization technology with a non-root User.
    This is a very bad idea although people always ask about it, and solutions are posted… Because this is not much different than logging in to your system using a root account. Similar to this, there have been past vulnerabilities and exploits when the hypervisor is compromised and a malicious hacker gains access to your network because when this happens, the attacker gains root access to the Guest and from there can compromise anything your Guest has access to… through Unix sockets, network sockets, limited only by the imagination.

The significant difference with Virtualbox is that it doesn’t run as a daemon that launches on boot by default… It’s launched manually by a User for only a relatively short time, Virtualbox is still not running after the User logs out and shuts down.

Bottom line is that if your virtualization needs are to use vms only when you’re logged in, then use Virtualbox.
If your needs are more “Enterprise” where your machines run 24/7, then use virtualization that runs even when you’ve logged out.
There shouldn’t be any problem running both Virtualbox and KVM/QEMU on the same machine.
If you decide to run Virtualbox in daemon mode you can use Vbox manager tools or even libvirt or vagrant to manage your vms.

Still,
If you want to run run virsh as an unprivileged User, libvirt describes how to do it by making the libvirt daemon binary and your User account members of the same User Group
https://libvirt.org/auth.html
And you can find this in the openSUSE documentation, too
https://doc.opensuse.org/documentation/leap/virtualization/single-html/book.virt/#sec-libvirt-connect-auth
I thought I saw this use of a common User Group in QEMU documentation too but can’t find it at the moment.

Closing this point, a reminder to newbies to openSUSE…
Whereas the use of sudo is onerous and required to elevate in most distros,
openSUSE allows and encourages the use of su (or su- which is unnecessary for running virsh commands) continuously in a console. You elevate your console permissions only once, and until the console is closed you can execute as many commands as you want without elevating the permissions of every command individually.

  1. QEMU can provide some pretty cool hardware emulation capabilities if you’ have software that runs only on ARM, AS400, DEC, SPARC or hundreds of other architectures many which are no longer made or supported without actually scrounging up a real machine. But otherwise, I don’t know that a good case can be made for running qemu commands.
    So, the average User maybe 99% of the time should not be using QEMU commands, if libvirt is installed use virsh.

  2. I think there is misunderstanding what is happening when you grant access to the VM using the methods described in this Thread… When the mic is passed to the VM, the VM should have a monopolistic access and no other VM or even the HostOS should have access to the mic… There is no shared access, and this is a normal consequence of passing any device to a Guest.

  3. Creating network bridge devices can be done any number of ways, eg with the ip-link command, the legacy brctl tool, YaST, any virtualization technology, eg VMware, Virtualbox, libvirt. No matter how it’s created(some better than others), it’s usable by an vm (or even the HostOS) or virtual technology. So, for instance if you have Virtualbox, libvirt and KVM all installed on the same physical machine, you can create a bridge device in Virtualbox and use it in KVM. Or, configure its use through libvirt. The name of the bridge device does not matter, nor how it was created. Once created everything can use.

So, as an example in your posts you created a virbr0 bridge device with common bridging capability to access your LAN which should have been totally unnecessary because if you had created a br0 during your YaST virtualization install, you’ve simply created a duplicate. Instead of connecting your tap interface to virbr0, you could have connected it to br0 instead and the result would be the same.

Hope this clears up some things, and helps everyone make decisions what directions to go when using QEMU-KVM.

TSU

Hello

Now we add a webcam to our vm

  1. in order to capture video or just take a photo just add in the script

-device usb-host,vendorid=<vendorid>,productid=<productid> \

To find the vendorid and productid, type in a console the command “lsusb”

In my case i get this

x@grognon:~> lsusb
Bus 002 Device 002: ID 0bda:0321 Realtek Semiconductor Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 046d:08e5 Logitech, Inc.
Bus 001 Device 004: ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0
Bus 001 Device 003: ID 04d9:1702 Holtek Semiconductor, Inc. Keyboard LKS02
Bus 001 Device 002: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 006: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Find your webcam. The left hex number is the vendorid and the right hex number is the productid.

Becareful in qemu statement 046d becomes 0x046d. For example

-device usb-host,vendorid=0x046d,productid=0x08e5

you must add a dev rule in order the vm gets the right to use the microphone.

in /etc/udev/rules.d/

  • create a file 50.qemu.rules

in 50.qemu.rules

  • add the statement

<vendor name> <model name>

SUBSYSTEMS==“usb”, ATTRS{idVendor}=="<vendorid>", ATTRS{idProduct}=="<porductid>", GROUP=“kvm”, MODE=“0664”

This time copy the exact hex values supplied by lsusb.
for example

Logitech C920

SUBSYSTEMS==“usb”, ATTRS{idVendor}==“046d”, ATTRS{idProduct}==“08e5”, GROUP=“kvm”, MODE=“0664”

then refresh the dev rules.

su -c “udevadm control --reload-rules” <your login id>
su -c “udevadm trigger --attr-match=subsystem=usb” <your login id>

With Yast user&group management software set you as a member of the group “kvm”

  1. the new script to launch the vm

don’t forget to supply the hex values of the “vendorid” and “productid”


#!/bin/bash

qemu-kvm \
-enable-kvm \
-m 2048 \
-smp 2 \
-cpu host \
-vga qxl \
-device usb-ehci \
-device usb-kbd \
-device usb-mouse \
-device usb-tablet \
-device intel-hda \
-device hda-output,audiodev=snd0 \
-audiodev pa,id=snd0 \
-device usb-host,vendorid=<hex value>,productid=<hex value> \
-boot menu=on \
-nic bridge \
~/QEMU_VM/android_x86_7.1-r5.img \


  1. I experimented that
  • it works well with Skype and Opencamera.

  • incompletely with Whatsapp: webcam mic works well to record audio but not during video call.

I found a workaround :

  • add a jack micro to your PC
  • use “-device hda-duplex,audiodev=snd0” instead of “-device hda-output,audiodev=snd0”

“-device hda-duplex” in order to capture the “line in” and “line out” of the host

Don’t be afraid, speakers and jack mic are shared dynamically.

I verified it works well with Opencamera, Skype and Whatsapp.

With Whatsapp during video call the sent image of you is slow and with low quality. Thus, your voice is not synchronized with image.
The image of the person with whom you discuss is good and with normal speed.

Perhaps you may

  • add an usb microphone
  • and stay with “-device hda-output,audiodev=snd0”
  1. Finally, the new script is

#!/bin/bash

qemu-kvm \
-enable-kvm \
-m 2048 \
-smp 2 \
-cpu host \
-vga qxl \
-device usb-ehci \
-device usb-kbd \
-device usb-mouse \
-device usb-tablet \
-device intel-hda \
-device hda-duplex,audiodev=snd0 \
-audiodev pa,id=snd0 \
-device usb-host,vendorid=<hex value>,productid=<hex value> \
-boot menu=on \
-nic bridge \
~/QEMU_VM/android_x86_7.1-r5.img \


Enjoy :slight_smile:

  1. How to launch the vm at login and to put it in the systray ?

You need to install “kdocker” and “wmctrl” apps

with kde plasma we can launch login script. Just add your script in “kde settings” > “start & stop” > “automatically start”

add “kdocker” (without ") in “kde settings” > “start & stop” > “desktop session” > “don’t restore these apps”

here is a login script


#!/bin/bash

sleep 2m 15s

bash -c '
qemu-kvm \
-enable-kvm \
-m 2048 \
-smp 2 \
-cpu host \
-vga qxl \
-device usb-ehci \
-device usb-kbd \
-device usb-mouse \
-device usb-tablet \
-device ich9-intel-hda \
-device hda-duplex,audiodev=snd0 \
-audiodev pa,id=snd0 \
-device usb-host,vendorid=0x046d,productid=0x08e5 \
-boot menu=on \
-nic bridge \
~/QEMU_VM/android_x86_7.1-r5.img \
' &

while  true ]
do
   sleep 5s
   status=$(wmctrl -l | grep "QEMU")
   if  "$status" != "" ] ; then
      break
   fi
done
WID="$(wmctrl -lx | grep "QEMU")"; kdocker -qtw "${WID%% *}" -i /usr/share/icons/hicolor/32x32/apps/package_system_emulator.png &




Some explanations:

Why “sleep 2m 15s” ?
Because at login many things are launched in my case. To avoid a problem I wait for a calm period.
Feel free to adapt it.

The script waits for a window with title “QEMU”. Perhaps in the futur the title will change. Be prepared to change the title in the script.

Perhaps you need to change the icon I use for the vm in the systray.

If you want to launch on demand the vm because you close it you can make another script by deleting “sleep 2m 15s”

  1. How to shut down the vm at logout or shutdown ?

It is not necessary to use a logout script. Just logout or shutdown.

Enjoy :slight_smile:

A goog news.

You remember that :

qemu-xhci + webcam => webcam speed matching problem.

I solved the problem by using"usb-ehci". I get only a few warnings but this work.

I updated qemu from 4.2.1 to 5.2.0 then no more problem using “qemu-xhci” No speed mismatching, no warnings.

Furthermore, I preferred to use “qemu-xhci” because it is a more generic option and more compliant with devices.

Today I want to solve an annoying problem.

I get a keyboard with the standard keys layout defined by IBM Model M 101/102 keys. This is the standard for desktop PC. This keyboard gets a built-in numerical keypad, an arrow keypad , etc. With “-device usb-kbd” only the equivalent of a laptop PC keyboard is enabled with android-x86.
It is not comfortable.

I know that we can plug our desktop PC keyboard in a smartphone and using all the keys.

Thus, I trie in the script this:

  • I delete "-device usb-kbd "
  • I add "-device usb-host,vendorid=0x04d9,productid=0x1702 "
  • I add an udev rule in qemu.rules for the keyboard to get the rights to use it in qemu. Please follow the same procedure to add a webcam. See above.

SUCCESS

Android-x86 takes care of the keyboard. I can use all the keys ! I just need to lock the numerical keypad.

SUCCES ? NO.

I forget that all devices added by “-device usb-host,” are shared statically. I can’t use my keyboard simultaneously with the host.
I get speed mismatching error for webcam.

So I must revert to “-device usb-ehci” and “-device usb-kbd”.

Sorry for the disappointment.

usefull knowledge about qemu-xhci.

If you get speed mismatch errors when adding a webcam or something else with “-device usb-host” then the error messages are false. In fact there is not enought usb port to add the webcam.

I must use in my case 5 ports at least “-device qemu-xhci,p2=5,p3=5” then no more errors.

But the webcam image is not good in the contrary of using “-device usb-ehci”.

I found a manual workaround of the problem “no numeric keypad in the vm”

After launching the vm

go and click in the vm window
hit the key “numlock”. the “numlock” light is switched off.
go and click in the host desktop.
hit the key “numlock”. the “numlock” light is switched on.

That’s all. you can use numeric keypad in the host and guest.

HOW to get 3D accel ?

  1. You need to install the last version of libvirt (7.0.0),qemu (5.2.0), virgl renderer 0.8.2

For this

  • with Yast sofware manager install the repo

https://download.opensuse.org/repositories/home:frispete:15.2:kvm/openSUSE_Leap_15.2

name it “Current KVM Builds”

  • refresh the repo

  • return to the package management

  • go to the repo “Current KVM Builds”

  • click on “replace the system packages” and refuse to delete postfix

replace “-device qxl” by “-device virtio-vga,virgl=on -display gtk,gl=on”

there is a caveat. i get a tiny window.
qemu does not take care automatically of the kernel option “vga=1280x960”.
i must in “view” menu of the vm uncheck “zoom to fit” to get a window of size 1290x960.

In my case 3D accel is useless but perhaps for you it is useful.

Enjoy :slight_smile: