Hello. I would like to be able to use runqemu in bridge networking mode, but the hard-coded device type causes issues with some machine configs using Xilinx BSP layers.
This is an attempt to resolve that, and also to support multiple simultaneous VMs by substituting the @MAC@ pattern similar to the other networking backend modes. The problem is that in bridged mode I had difficulty thinking of a good source for deterministic unique MAC generation, so a suffix syntax is introduced to the runqemu bridge= argument. This is not as automatic as the MAC handling in the other networking modes. I welcome any discussion or suggestions to improve the patch. Thanks, Corey
From aec797bc000afe315abc2faf85ac3b68702d5c7c Mon Sep 17 00:00:00 2001 From: Corey Thompson <[email protected]> Date: Fri, 26 Aug 2022 15:58:44 -0400 Subject: [PATCH] runqemu: Use qb_network_device in setup_net_bridge() Remove a hard-coded network device and use the qemuboot.conf-supplied qb_network_device setting, complete with @MAC@ substitution. Because there is no deterministic hint that can be used for unique MAC address generation in this mode, an optional ":<offset>" suffix may be provided to the "bridge=" parameter so that the user may bring up multiple VMs each with a different and predictable MAC. --- scripts/runqemu | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/scripts/runqemu b/scripts/runqemu index 66e035c9af..ec6889e6e5 100755 --- a/scripts/runqemu +++ b/scripts/runqemu @@ -208,6 +208,7 @@ class BaseConfig(object): # slirp qemus are running. self.mac_tap = "52:54:00:12:34:" self.mac_slirp = "52:54:00:12:35:" + self.mac_bridge = "52:54:00:12:36:" # pid of the actual qemu process self.qemupid = None # avoid cleanup twice @@ -1046,8 +1047,27 @@ class BaseConfig(object): self.nfs_running = True def setup_net_bridge(self): - self.set('NETWORK_CMD', '-netdev bridge,br=%s,id=net0,helper=%s -device virtio-net-pci,netdev=net0 ' % ( - self.net_bridge, os.path.join(self.bindir_native, 'qemu-oe-bridge-helper'))) + """Setup bridged tap networking""" + + # In this case there is no good source for deterministic unique mac + # generation. Allocation of the tap interface is delegated to qemu, so + # we cannot use the tap number as a hint as in setup_tap(), nor are + # there port forward options as in setup_slirp(). Instead, the user + # must provide a unique suffix to the "bridge=" option delimited with a + # colon to start multiple qemus, e.g., + # runqemu bridge=virbr0 # no suffix; default to mac+0 + # runqemu bridge=virbr0:1 # mac+1 + # runqemu bridge=virbr0:2 # mac+2 + # ... and so on ... + try: + net_bridge, mac = self.net_bridge.split(":") + mac = int(mac) + except ValueError: + net_bridge, mac = self.net_bridge, 0 + mac = '%s%02x' % (self.mac_bridge, mac) + self.set('NETWORK_CMD', '%s -netdev bridge,br=%s,id=net0,helper=%s' % ( + self.network_device.replace("@MAC@", mac), net_bridge, + os.path.join(self.bindir_native, 'qemu-oe-bridge-helper'))) def setup_slirp(self): """Setup user networking""" -- 2.35.1
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#170016): https://lists.openembedded.org/g/openembedded-core/message/170016 Mute This Topic: https://lists.openembedded.org/mt/93329703/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
