# QEMU and bridge networking [SOLVED] w/ADDENDUM

## dufeu

I had wanted to do a stage 3 install on a QEMU virtual box but I can't seem to get past network configuration. I feel I'm either missing a piece or it's a 'chicken and egg' situation.

This is what I've got/done so far:

Check kernel configuration:

```
# grep KVM /usr/src/linux/.config

CONFIG_HAVE_KVM=y

CONFIG_HAVE_KVM_IRQCHIP=y

CONFIG_HAVE_KVM_IRQFD=y

CONFIG_HAVE_KVM_IRQ_ROUTING=y

CONFIG_HAVE_KVM_EVENTFD=y

CONFIG_KVM_APIC_ARCHITECTURE=y

CONFIG_KVM_MMIO=y

CONFIG_KVM_ASYNC_PF=y

CONFIG_HAVE_KVM_MSI=y

CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y

CONFIG_KVM_VFIO=y

CONFIG_KVM=y

# CONFIG_KVM_INTEL is not set

CONFIG_KVM_AMD=y

CONFIG_KVM_DEVICE_ASSIGNMENT=y

# grep BRIDGE /usr/src/linux/.config

# CONFIG_BRIDGE_NF_EBTABLES is not set

CONFIG_BRIDGE=y

CONFIG_BRIDGE_IGMP_SNOOPING=y

# grep CONFIG_TUN /usr/src/linux/.config

CONFIG_TUN=y
```

Check for kvm capability:

```
# grep --color -E "vmx|svm" /proc/cpuinfo

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs hw_pstate npt lbrv svm_lock vmmcall

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs hw_pstate npt lbrv svm_lock vmmcall

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs hw_pstate npt lbrv svm_lock vmmcall

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs hw_pstate npt lbrv svm_lock vmmcall

# ls -l /dev/kvm

crw-rw----+ 1 root kvm 10, 232 May 13 12:09 /dev/kvm
```

Emerge needed packages:

```
# echo 'app-emulation/qemu -accessibility spice' >> /etc/portage/packag.use/emulation

# emerge app-emulation/qemu sys-apps/usermode-utilities net-misc/bridge-utils
```

Create the image:

```
qemu-img create -f qcow2 /pubroot/qemu/test01 10G
```

For the installation media, I'm using 'systemrescuecd' as I already have a copy of the iso on my host computer. Boot the image using the installation iso:

```
qemu-system-x86_64 -cpu host -cdrom /sysrescd/systemrescuecd-x86-4.5.2.iso -boot order=d -enable-kvm /pubroot/qemu/test01
```

According to my reading, this is supposed to be 'passthrough'  with VirtIO support. If I've understood what I've read correctly, it can't see anything on my lan or local host nor can anything see it. This is obviously not what I want as I need to be able to see at least the DNS server and gateway on my network.

So far, all works as expected. Running 'startx' on sysrescd's command line brings up the GUI and everything is pretty snappy.

My understanding from the 'help' in the kernel is that '[tap|tun]0' is created and destroyed at need:

```
When a program opens /dev/net/tun, driver creates and registers

corresponding net device tunX or tapX.  After a program closed above

devices, driver will automatically delete tunXX or tapXX device and

all routes corresponding to it.
```

I therefore expected 'qemu-system-x86_64' to automatically create (in my case) 'vnet0' when I gave it the option to do so:

```
$ qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 512 -netdev tap,id=t0,ifname=vnet0,script=no,downscript=no -device e1000,netdev=t0 -cdrom /sysrescd/systemrescuecd-x86-4.5.2.iso -boot order=d /pubroot/qemu/test01
```

Instead it refused and googling did not provide any useful leads:

```

qemu-system-x86_64: -netdev tap,id=t0,ifname=vnet0,script=no,downscript=no: could not configure /dev/net/tun (vnet0): Operation not permitted

qemu-system-x86_64: -netdev tap,id=t0,ifname=vnet0,script=no,downscript=no: Device 'tap' could not be initialized
```

Based on what I've read, I'm assuming I need to bind the QEMU virtual network to the host nic with bridging. To do that, I need to change /etc/conf.d/net, have 'vnet0' present and use the 'bridge' utilities.

But I'm kind of stuck at this point and only have vague ideas of what I should actually be doing and I don't have any good leads as to what I'm missing.

Help!  :Wink: 

Oh yeah - I don't use systemmd and my current /etc/conf.d/net configuration is:

```
# We need a domain to support Windows Network/Samba workgroups.

dns_domain_lo="lamasondufeu"

# This device has a fixed address because it advertises possible

# NFS and Samba file shares.

config_eth0="192.168.1.198 netmask 255.255.255.0"

routes_eth0="default via 192.168.1.1"

dns_servers_eth0="192.168.1.1 8.8.4.4 208.67.222.222"
```

edited to reflect further info:

I did change /etc/conf.d/net to:

```
# We need a domain to support Windows Network/Samba workgroups.

dns_domain_lo="lamasondufeu"

# This device has a fixed address because it advertises possible

# NFS and Samba file shares.

# config_eth0="192.168.1.198 netmask 255.255.255.0"

# routes_eth0="default via 192.168.1.1"

# dns_servers_eth0="192.168.1.1 8.8.4.4 208.67.222.222"

#Configure TUN/TAP interface

tuntap_vnet0="tap"

 

# Set vnet0 and eth0 to null so that DHCP doesn't try to assign IP

# addresses to them.

config_vnet0=null

config_eth0=null

 

# Configure network bridge

# Get Bridge IP address from DHCP

# config_br0="dhcp"

# OR explicitly assign an IP address to Bridge.

config_br0="192.168.1.198/24"

# Add a MAC address to Bridge.

mac_br0="aa:bb:cc:dd:ee:ff"

# Define the Bridge (list all the interfaces for bridge). One tap[0-9] per VM

bridge_br0="eth0 vnet0"

# Indicate to OpenRC that we need 'eth0' and 'vnet0' before bridge is created.

rc_net_br0_need="net.eth0 net.vnet0"

# set DNS values for br0

dns_servers_br0="192.168.1.1 8.8.4.4 208.67.222.222"
```

and tried the following:

```
# ln -s /etc/init.d/net.lo /etc/init.d/net.vnet0

# ln -s /etc/init.d//net.lo /etc/init.d/net.br0

# /etc/init.d/net.eth0 stop

# /etc/init.d/net.br0 start
```

The VM gained access to my local LAN and the Internet while my host retained access to my local LAN and could no longer access the Internet.

I guess I'm down to a /etc/conf.d/net conficguration issue but that's purely a guess.  :Wink: 

----------

## John R. Graham

Moved from Installing Gentoo to Networking & Security as requested.

- John

----------

## dufeu

This has turned into a more general issue of bridge networking configuration with QEMU.

I've been reading and attempting to follow these pages:QEMU - Gentoo wiki

QEMU/Options - Gentoo wiki page on QEMU options including bridge networking

Network bridge - Gentoo wiki

Handbook:Parts/Networking/Advanced - Gentoo Handbook

QEMU/Networking - TAP/TUN device - Wikibooks - dated - Basically describes script environment expectations

QEMU - Arch wiki

Features-Done/HelperNetworking - Official QEMU page on networking helper. Doesn't cover how host should be set up.

In addition to the above links, I've also noted a few other interesting tidbits.The installation of QEMU includes installing /etc/qemu/bridge.conf. Everything is commented out by default. None of the documentation/guides I've read mention this file. This file is apparently for the QEMU networking helper. I've seen no 3rd party discussions on how to use this.

There is also no '--config' option in the ebuild. This doesn't surprise me as I didn't expect one but I checked anyway because of the installation of the 'bridge.conf' file.

Along the same lines, there is no qemu start/stop script installed in /etc/init.d/. I wouldn't expect one anyway but just mentioned this for completeness.

This is what the /etc/qemu/bridge.conf file:

```
# This should have the following permissions: root:qemu 0640

# allow br0

# Uncommenting the above would allow users in the 'qemu' group

# to add devices to 'br0'

# allow virbr0

# Uncommenting the above would allow users in the 'qemu' group

# to add devices to 'virbr0'

# include /etc/qemu/bob.conf

# Uncommenting the above would allow users in the 'bob' group

# to have permissions defined in it, iff it has the following

# permissions: root:bob 0640
```

Based on my readings and my interpertation of what they might mean, I've refined what I expect my /etc/conf.d/net file should look like:

```
#       We need a domain to support Windows Network/Samba workgroups.

dns_domain_lo="lamasondufeu"

#       This device has a fixed address because it advertises possible

#       NFS and Samba file shares.

#       old config w/out bridge

# config_eth0="192.168.1.198 netmask 255.255.255.0"

# routes_eth0="default via 192.168.1.1"

# dns_servers_eth0="192.168.1.1 8.8.4.4 208.67.222.222"

#       Configure TUN/TAP interface

#       We'll use naming scheme vnet[0-9] for our QEMU VMs We need one

#       vnet[] for each VM instance. Set 'vnet[0-9]' to type 'tap'

tuntap_vnet0="tap"

# tuntap_vnet1="tap"

# tuntap_vnet2="tap"

 

#       Set eth0 and vnet[0-9] to null so that DHCP doesn't try to assign IP

#       addresses to them.

config_eth0=null

config_vnet0=null

# config_vnet0=null

# config_vnet0=null

 

#       Configure network bridge

#       Get Bridge IP address from DHCP

# config_br0="dhcp"

#       OR explicitly assign an IP address to Bridge.

config_br0="192.168.1.198/24"

#       Add a MAC address to Bridge. (optional)

# mac_br0="aa:bb:cc:dd:ee:ff"

#       Define the Bridge (list all the interfaces for bridge). One vnet[0-9] per VM

bridge_br0="eth0 vnet0"

# Indicate to OpenRC that we need 'eth0' and 'vnet[0-9]' before bridge is created.

rc_net_br0_need="net.eth0 net.vnet0"

rc_net_lo_provide="!net"

rc_net_eth0_provide="!net"

rc_net_vnet0_provide="!net"

# rc_net_vnet0_provide="!net"

# rc_net_vnet0_provide="!net"

#       set DNS values for br0

dns_servers_br0="192.168.1.1 8.8.4.4 208.67.222.222"
```

I'm quite certain it's wrong because I'm quite certain my understanding of what's going on is wrong/incomplete. The above /etc/conf.d/net configuration file results in my QEMU VMs having access to my LAN and to the Internet while my host can access my LAN but not the Internet.

For QEMU VM networking where I want each VM instance to look like just another computer on my LAN with standard access to the Internet, it seems I need to bring down networking, reconfigure the bridge and then bring network back up for each VM I want to run. 

Some quidance/pointers/help would be very much appreciated!

 :Wink: 

----------

## szatox

Well, technicaly you don't NEED any interfaces to create a bridge. You can have it up and running while still hanging in the air and enslave interfaces as you need them. Handy thing for configuring dhcpd (start it bound to the bridge and add interfaces later instead of restarting it every time you want to add something).

Now, what you pasted seems to be correct. I wonder about things you haven't pasted. Just a wild guess: default gateway is missing.

----------

## footfall

I have a similar setup and after a bit of trial and error have a VM and the Host with full internet access.

I mostly followed the guides here:

http://wiki.qemu.org/Features/HelperNetworking

https://wiki.gentoo.org/wiki/Network_bridge

I ran the following:

```

emerge net-misc/bridge-utils

brctl addbr br0

brctl addif br0 enp0s25

ln -s /etc/init.d/net.lo /etc/init.d/net.br0

/etc/init.d/net.br0 start 

rc-update add net.br0 default

```

My network config /etc/conf.d/net:

```

config_enp0s25="null"

# bridge

config_br0="dhcp"

brctl_br0="setfd 0

sethello 10

stp off"

bridge_br0="enp0s25"

```

Check you /etc/qemu/bridge.conf file - it looks like you need to uncomment the line "#allow br0". Mine is:

```

allow br0

```

And start the VM with the -netdev option (which defaults to bridge br0):

```

qemu-system-x86_64 -enable-kvm -cpu host \

  -drive file=/srv/vms/minecraft-vm.img,if=virtio \

  -netdev bridge,id=hn0 -device virtio-net-pci,netdev=hn0,id=nic1 \

  -m 4G -monitor stdio

```

----------

## dufeu

 *szatox wrote:*   

>  .. Just a wild guess: default gateway is missing.

 Actually yes. This turned out to be one of the problems. I'm not exactly sure how I missed that since I knew I needed to set everything for br0 that I originally set for eth0. In fact, that's why I left the original eth0 config (commented out) in place!

 *footfall wrote:*   

>  .. I have a similar setup and after a bit of trial and error have ..

  Your examples were helpful in clarifying the seperation of host side changes/infrastructure and what is proplerly the pervue of qemu's execution of the client side. I was getting to the point of realizing that all I needed in /etc/conf.d/net was the host side configuration only for br0. It's quite clear at this point that upstream has refined networking quite a bit and what was true even a short while ago is no longer preferred practice.

My /etc/conf.d/net file now looks like this:

```
#       We need a domain to support Windows Network/Samba workgroups.

dns_domain_lo="lamasondufeu"

#       This device has a fixed address because it advertises possible

#       NFS and Samba file shares.

#       old config w/out bridge

# config_eth0="192.168.1.198 netmask 255.255.255.0"

# routes_eth0="default via 192.168.1.1"

# dns_servers_eth0="192.168.1.1 8.8.4.4 208.67.222.222"

#       Set eth0 to null so that DHCP doesn't try to assign IP

#       addresses to them.

config_eth0=null

 

#       Configure network bridge - we can use DHCP or explicitly set IP address

#       Get Bridge IP address from DHCP

# config_br0="dhcp"

#       OR explicitly assign an IP address to Bridge.

config_br0="192.168.1.198/24"

#       (optional) Add a MAC address to Bridge. If you use MAC filtering then you

#       probably want to set this statically. Otherwise the MAC address will be

#       generated randomly.

# mac_br0="00:16:1c:1d:1e:1f"

#       Define the Bridge (list all ACTIVE interfaces for bridge).

#       At start up, only the host nic is actually up to be added to the bridge.

bridge_br0="eth0"

#       Indicate to OpenRC that we need 'eth0' before bridge is created.

rc_net_br0_need="net.eth0"

#       Indicate to OpenRC that the lo and any bridged interfaces do not satisfy

#       'need net'.

rc_net_lo_provide="!net"

rc_net_eth0_provide="!net"

#       set DNS values for br0

dns_servers_br0="192.168.1.1 8.8.4.4 208.67.222.222"

#       set default gateway for br0

routes_br0="default via 192.168.1.1"
```

I did have the correct value of 'allow br0' in /etc/qemu/bridge.conf:

```

allow br0

# Uncommenting the above would allow users in the 'qemu' group

# to add devices to 'br0'

allow virbr0

# Uncommenting the above would allow users in the 'qemu' group

# to add devices to 'virbr0'

# include /etc/qemu/bob.conf

# Uncommenting the above would allow users in the 'bob' group

# to have permissions defined in it, iff it has the following

# permissions: root:bob 0640
```

I use this command to start my first qemu session:

```
qemu-system-x86_64 -enable-kvm -cpu host -m 1024 -smp 2 -netdev bridge,id=vnet0 -device virtio-net-pci,netdev=vnet0,id=nic1 -cdrom /sysrescd/systemrescuecd-x86-4.5.2.iso -boot order=d /pubroot/qemu/guynonet-q01
```

This works great and as expected.

I tried to set up a second qemu session like so:

```
qemu-system-x86_64 -enable-kvm -cpu host -m 1024 -smp 2 -netdev bridge,id=vnet1 -device virtio-net-pci,netdev=vnet1,id=nic1 -cdrom /sysrescd/systemrescuecd-x86-4.5.2.iso -boot order=d /pubroot/qemu/guynonet-q02
```

All I'm doing is setting the id if the virtual nic to be 'vnet1' and to use disk image '/pubroot/qemu/guynonet-q02'. This session comes up as expected but with one wee little problem.

The built in DHCP server in the firewall ends up assigning the same IP address to both qemu sessions.

When I check 'ifconfig -a' on the first qemu session, it displays:

```
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.1.4  netmask 255.255.255.0  broadcast 192.168.1.255

        inet6 fe80::5054:ff:fe12:3456  prefixlen 64  scopeid 0x20<link>

        ether 52:54:00:12:34:56  txqueuelen 1000  (Ethernet)

        RX packets 802  bytes 260814 (254.7 KiB)

        RX errors 0  dropped 30  overruns 0  frame 0

        TX packets 43  bytes 3773 (3.6 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
```

When I check 'ifconfig -a' on the second qemu session. it displays:

```
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.1.4  netmask 255.255.255.0  broadcast 192.168.1.255

        inet6 fe80::5054:ff:fe12:3456  prefixlen 64  scopeid 0x20<link>

        ether 52:54:00:12:34:56  txqueuelen 1000  (Ethernet)

        RX packets 1014  bytes 327043 (319.3 KiB)

        RX errors 0  dropped 26  overruns 0  frame 0

        TX packets 87  bytes 8773 (8.5 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
```

When I check 'ifconfig -a' on the host, it displays .. clipped to only show 'tap' entries ..:

```
tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet6 fe80::fc68:6cff:fe09:5750  prefixlen 64  scopeid 0x20<link>

        ether fe:68:6c:09:57:50  txqueuelen 500  (Ethernet)

        RX packets 23  bytes 2194 (2.1 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 577  bytes 147650 (144.1 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet6 fe80::fc60:13ff:fede:4216  prefixlen 64  scopeid 0x20<link>

        ether fe:60:13:de:42:16  txqueuelen 500  (Ethernet)

        RX packets 64  bytes 6776 (6.6 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 420  bytes 108720 (106.1 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
```

What else do I need? Or, can I assign a static IP address to a qemu session in the qemu command line?

----------

## szatox

 *Quote:*   

> 
> 
> qemu1
> 
> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> ...

 

See the failure?

From the point of view of any remote host, including dhcp, you only have 1 virtual machine with only 1 interface. And if you open TCP connetion from one of those, the other should interrupt it with reset flag (unless you silently drop unwanted traffic)

Using random MAC helps a lot.

I suppose you can adapt this line to your needs:

 *Quote:*   

> -net nic,macaddr=$( printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256)) ),vlan=$i -net tap,ifname=$name-$i,script=no,downscript=no,vlan=$i"

 

I'm using quite different way to set networking, but it hardly matters, striping expendable stuff is easy

----------

## dufeu

 *szatox wrote:*   

> See the failure?
> 
> From the point of view of any remote host, including dhcp, you only have 1 virtual machine with only 1 interface. 
> 
> ..
> ...

 

I read too much information. I started out reading the QEMU docs and ran across this suggestion there. Then I read the 'bridge' docs and read the 'mac' address is randomized there {except for the first two tuples} and then forgot the mac on QEMU isn't randomized.

Thanks! I'll play around with this now.

 :Smile: 

----------

## dufeu

Everything now works as expected.

However, there is still a 'gotcha' lurking about.

The qemu command has two different options for defining networking infrastructure. These are '-net' and '-netdev'. According to upstream, '-net' is deprecated in favor of '-netdev' since qemu-1.2. {look for 'The legacy -net option'}

In the instance of setting the mac address you want to use, the syntax between '-net' and '-netdev' varies between 'macaddr=' and 'mac=' respectively. i.e. szatox's example above is for '-net'. 

For the 'netdev' option, the syntax for mac address assignment looks like:

```
mac=$( printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256)) )
```

The following commands work:For first QEMU session located at /pubroot/qemu/session-q01:

```
qemu-system-x86_64 -enable-kvm -cpu host -m 1024 -smp 2 -netdev bridge,id=vnet0 -device virtio-net-pci,netdev=vnet0,mac=$( printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256)) ) -cdrom /sysrescd/systemrescuecd-x86-4.5.2.iso -boot order=d /pubroot/qemu/session-q01
```

For second QEMU session located at /pubroot/qemu/session-q02:

```
qemu-system-x86_64 -enable-kvm -cpu host -m 1024 -smp 2 -netdev bridge,id=vnet1 -device virtio-net-pci,netdev=vnet1,mac=$( printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256)) ) -cdrom /sysrescd/systemrescuecd-x86-4.5.2.iso -boot order=d /pubroot/qemu/session-q02
```

Note that you can explicitly assign any static mac address you want depending on your needs.

----------

## szatox

 *Quote:*   

> These are '-net' and '-netdev'. According to upstream, '-net' is deprecated in favor of '-netdev' since qemu-1.2. 

 thanks for picking it up, I did know that wrapper I use is a bit outdated, but didn't expect this part to be off as well.

Perhaps it's a time for rewrite, hopefully doing it right this time  :Laughing: 

 *Quote:*   

> Note that you can explicitly assign any static mac address you want depending on your needs.

  Of course, this approach can sometimes even be justified. 

I like the randomized way more for it enables a single wrapper script to launch multiple machines at the same time (and even attach them to different numbers of networks)

----------

## dufeu

 *szatox wrote:*   

>  *Quote:*   Note that you can explicitly assign any static mac address you want depending on your needs.  Of course, this approach can sometimes even be justified.

 I once knew some network admins who's idea of wi-fi security was to a) restrict access to wi-fi through mac address and to b) associate mac addresses with permenently assigned IP addresses.

This is not a use case I can agree with.

I think the only use case for statically assigned mac addresses I can {somewhat} support, has to do with some older ISP provided Internet connection equipment.

OTOH, there are always people who insist on only doing things their one true way, regardless.

 *szatox wrote:*   

> I like the randomized way more for it enables a single wrapper script to launch multiple machines at the same time (and even attach them to different numbers of networks)

 

I agree with you.

Thank you again for your help.

----------

## dufeu

For the default network topologies, users can execute QEMU instances so long as they are part of the qemu group.

However ..

Upstream documentation has this to say regarding the use of 'bridge' utilities {use of 'Tap' as networking backend} with QEMU for constructing your network topolgy: *Quote:*   

>  .. Generally speaking, it also requires that you have root privileges.

 

This means you need to enable the 'sudo' package if you want your users {or your own normal user login} to be able to execute 'qemu' with 'bridge' network topology. This should go without saying but I'll say it anyway, it also means you need to use 'visudo' to edit the 'sudoers' file to enable your regular users.

If a user attempts to execute 'qemu' with 'bridge' networking, they will see the following error or similar depending on what other '-netdev' options are chosen/defined:

```
failed to drop privileges

failed to launch bridge helper

qemu-system-x86_64: -netdev bridge,id=vnet0: Device 'bridge' could not be initialized
```

Once you've enabled a user/group(s) of users for 'qemu', then properly constructed commands similar to this will work:

```
$ sudo qemu-system-x86_64 -enable-kvm -cpu host -m 1024 -smp 2 -netdev bridge,id=vnet0 -device virtio-net-pci,netdev=vnet0,mac=$( printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256)) ) -cdrom /sysrescd/systemrescuecd-x86-4.5.2.iso -boot order=d /pubroot/qemu/guynonet-q01
```

Have fun!

----------

