| View previous topic :: View next topic |
| Author |
Message |
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
 Posted: Wed May 13, 2015 11:18 pm Post subject: QEMU and bridge networking [SOLVED] w/ADDENDUM |
 |
|
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:
| Code: | # 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: | Code: | # 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: | Code: | # 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: | Code: | | 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: | Code: | | 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: | Code: | 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: | Code: | | $ 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: | Code: |
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! 
Oh yeah - I don't use systemmd and my current /etc/conf.d/net configuration is: | Code: | # 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: | Code: | # 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: | Code: | # 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.
_________________
People whom think M$ is mediocre, don't know the half of it.
Last edited by dufeu on Wed May 27, 2015 9:24 pm; edited 4 times in total |
|
| Back to top |
|
 |
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10589
Location: Somewhere over Atlanta, Georgia
|
| Posted: Thu May 14, 2015 2:35 pm Post subject: |
|
|
Moved from Installing Gentoo to Networking & Security as requested.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Thu May 14, 2015 4:01 pm Post subject: |
|
|
This has turned into a more general issue of bridge networking configuration with QEMU.
I've been reading and attempting to follow these pages:
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: | Code: | # 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: | Code: | # 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!
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3137
|
| Posted: Mon May 18, 2015 6:40 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
footfall
n00b
Joined: 24 Jul 2003
Posts: 7
Location: London
|
| Posted: Fri May 22, 2015 11:23 am Post subject: |
|
|
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:
| Code: |
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:
| Code: |
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:
And start the VM with the -netdev option (which defaults to bridge br0):
| Code: |
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
|
|
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Sun May 24, 2015 11:48 pm Post subject: |
|
|
| 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: | Code: | # 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: | Code: |
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: | Code: | | 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: | Code: | | 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: | Code: | 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: | Code: | 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 ..: | Code: | 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?
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3137
|
| Posted: Mon May 25, 2015 7:46 pm Post subject: |
|
|
| Quote: |
qemu1
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
qemu2
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 |
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 |
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Tue May 26, 2015 6:31 pm Post subject: |
|
|
| 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 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 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.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Tue May 26, 2015 7:54 pm Post subject: |
|
|
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: | Code: | | 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:
| Code: | | 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: | Code: | | 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.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3137
|
| Posted: Tue May 26, 2015 8:27 pm Post subject: |
|
|
| 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 
| 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) |
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Tue May 26, 2015 9:09 pm Post subject: |
|
|
| 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.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Wed May 27, 2015 9:23 pm Post subject: Addendum |
|
|
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: | Code: | 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: | Code: | | $ 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!
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
