--- title: Networking Aspects of Running VMs in Containers «... description: A deep technical walkthrough of how vrnetlab and its containerlab fork run virtual machines (typically network device OS images) inside containers, explaining... canonical: https://daily.dev/posts/networking-aspects-of-running-vms-in-containers-ipspace-net-blog-gttjndloc twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Networking Aspects of Running VMs in Containers « ipSpace.net blog | daily.dev og:description: A deep technical walkthrough of how vrnetlab and its containerlab fork run virtual machines (typically network device OS images) inside containers, explaining... og:url: https://daily.dev/posts/networking-aspects-of-running-vms-in-containers-ipspace-net-blog-gttjndloc og:image: https://api.daily.dev/og/posts/gtTjNDLOc.png og:image:alt: Networking Aspects of Running VMs in Containers « ipSpace.net blog og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Networking Aspects of Running VMs in Containers « ipSpace.net blog **[ipSpace.net Blog](https://daily.dev/sources/ipspace)** · 7 min read · 0 upvotes · 0 comments ## Summary A deep technical walkthrough of how vrnetlab and its containerlab fork run virtual machines (typically network device OS images) inside containers, explaining how QEMU's virtual NIC and tap interfaces are glued via Linux tc rules to container veth pairs to make data-plane and management interfaces work. It covers the original 2018 socat-based management proxy, the 2024/2025 switch to built-in QEMU port forwarding and the containerlab transparent management interface, and shows real ip link, ps, and tc output from a running OpenBSD VM container to illustrate the plumbing. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does vrnetlab connect a QEMU virtual machine's network interfaces to a container's veth pairs? It uses Linux tc (traffic control) rules to glue the container's veth interface to QEMU's tap interface. For a layer-2 data-plane interface, tc mirred redirect actions bridge frames between the veth pair's inside end and the tap interface, letting Ethernet frames flow to the QEMU virtual NIC emulation and ultimately to the VM. _Engineers wiring virtual lab topologies can track containerlab and vrnetlab networking changes on daily.dev._ ### How did containerlab's vrnetlab management interface handling change between 2018 and 2025? Originally in 2018, vrnetlab set a fixed management IP (10.0.0.15) on the VM and used socat as a TCP proxy to forward SSH traffic from the container's management IP. In 2024 socat was replaced with QEMU's built-in port forwarding, and in December 2024 a transparent management interface feature landed, shipping in containerlab release 0.62 in January 2025, copying the Docker-assigned eth0 IP to the VM's management interface. _Teams running netlab or containerlab labs can follow management-interface changes like this on daily.dev before they break automation._ ### Why does vrnetlab disable IPv6 and copy the VM's MAC address onto the container's eth0 interface? IPv6 is flushed on the container's tap interface to stop the container's own IPv6 stack from sending periodic traffic like router solicitations that would interfere with the passthrough. The VM's management MAC address is copied onto the container's eth0 so gratuitous ARPs sent by the VM don't create duplicate ARP entries or MAC conflicts, while ports 5000-5007 stay reserved for the container's own TCP stack. _Anyone debugging container-to-VM networking hairballs can dig into tc and tap plumbing details on daily.dev._ --- Tags: [#infrastructure](https://daily.dev/tags/infrastructure) [View this post on daily.dev](https://daily.dev/posts/networking-aspects-of-running-vms-in-containers-ipspace-net-blog-gttjndloc) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Networking Aspects of Running VMs in Containers « ipSpace.net blog","url":"https://daily.dev/posts/networking-aspects-of-running-vms-in-containers-ipspace-net-blog-gttjndloc","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/networking-aspects-of-running-vms-in-containers-ipspace-net-blog-gttjndloc"},"datePublished":"2026-09-02T05:51:47.153Z","dateModified":"2026-09-02T05:52:12.233Z","description":"A deep technical walkthrough of how vrnetlab and its containerlab fork run virtual machines (typically network device OS images) inside containers, explaining...","image":"https://media.daily.dev/image/upload/s--58gMhC4P--/f_auto/v1722860399/public/Placeholder%2012","thumbnailUrl":"https://media.daily.dev/image/upload/s--58gMhC4P--/f_auto/v1722860399/public/Placeholder%2012","isAccessibleForFree":true,"articleSection":"ipSpace.net Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"ipSpace.net Blog","logo":"https://media.daily.dev/image/upload/s--xS7E82MT--/f_auto,q_auto/v1786438303/logos/ipspace?_a=BAMAMicg0","url":"https://daily.dev/sources/ipspace"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/networking-aspects-of-running-vms-in-containers-ipspace-net-blog-gttjndloc","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"infrastructure","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"ipSpace.net Blog","item":"https://daily.dev/sources/ipspace"},{"@type":"ListItem","position":3,"name":"Networking Aspects of Running VMs in Containers « ipSpace.net blog"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/networking-aspects-of-running-vms-in-containers-ipspace-net-blog-gttjndloc#faq","mainEntity":[{"@type":"Question","name":"How does vrnetlab connect a QEMU virtual machine's network interfaces to a container's veth pairs?","acceptedAnswer":{"@type":"Answer","text":"It uses Linux tc (traffic control) rules to glue the container's veth interface to QEMU's tap interface. For a layer-2 data-plane interface, tc mirred redirect actions bridge frames between the veth pair's inside end and the tap interface, letting Ethernet frames flow to the QEMU virtual NIC emulation and ultimately to the VM. Engineers wiring virtual lab topologies can track containerlab and vrnetlab networking changes on daily.dev."}},{"@type":"Question","name":"How did containerlab's vrnetlab management interface handling change between 2018 and 2025?","acceptedAnswer":{"@type":"Answer","text":"Originally in 2018, vrnetlab set a fixed management IP (10.0.0.15) on the VM and used socat as a TCP proxy to forward SSH traffic from the container's management IP. In 2024 socat was replaced with QEMU's built-in port forwarding, and in December 2024 a transparent management interface feature landed, shipping in containerlab release 0.62 in January 2025, copying the Docker-assigned eth0 IP to the VM's management interface. Teams running netlab or containerlab labs can follow management-interface changes like this on daily.dev before they break automation."}},{"@type":"Question","name":"Why does vrnetlab disable IPv6 and copy the VM's MAC address onto the container's eth0 interface?","acceptedAnswer":{"@type":"Answer","text":"IPv6 is flushed on the container's tap interface to stop the container's own IPv6 stack from sending periodic traffic like router solicitations that would interfere with the passthrough. The VM's management MAC address is copied onto the container's eth0 so gratuitous ARPs sent by the VM don't create duplicate ARP entries or MAC conflicts, while ports 5000-5007 stay reserved for the container's own TCP stack. Anyone debugging container-to-VM networking hairballs can dig into tc and tap plumbing details on daily.dev."}}]} ```