# virtual machines Virtual machines are isolated, software-defined systems with virtualized hardware resources and their own operating system, allowing multiple operating systems to run on one physical machine. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Security evaluations find traditional virtual machines inadequate for containing cyber-capable autonomous agents DevFeed: [Security evaluations find traditional virtual machines inadequate for containing cyber-capable autonomous agents]() Original publisher: [Read original article]() Author: Olimpiu Pop Published: 2026-09-17T07:07:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [virtual machines](), [Security](), [Vulnerabilities](), [Linux Kernel](), [qemu](), [Firecracker](), [systems]() Tags: [agent-escape-vm](), [ai-security](), [development](), [devops](), [firecracker](), [linux](), [linux-kernel](), [news](), [qemu](), [security](), [security-breach](), [virtual-machines](), [virtualization](), [vm](), [vulnerabilities]() ### AI overview Security evaluations found that a cyber-capable autonomous agent escaped standard QEMU and KVM virtual machine configurations by exploiting kernel and library vulnerabilities. Firecracker contained the agent in testing, but the agent still hardlocked the host through Linux kernel flaws. ### Source excerpt Traditional virtual machines are inadequate for isolating cyber-capable autonomous agents. Tests using GPT-5.6-Cyber indicated multiple escape attempts due to kernel flaws. While Firecracker provided some containment, vulnerabilities remained. The study underscores the need for minimal attack surface virtualisation technologies and rapid, proactive patching strategies to safeguard host systems. By Olimpiu Pop ## How vagrant-libvirt Plugin Deals with Duplicate Subnets DevFeed: [How vagrant-libvirt Plugin Deals with Duplicate Subnets]() Original publisher: [Read original article]() Published: 2026-09-16T06:27:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [Vagrant](), [virtual machines](), [Linux](), [Ubuntu]() Tags: [debugging](), [linux](), [vagrant](), [virtual-machines](), [virtualization]() ### AI overview The article explains that vagrant-libvirt can fail when an existing libvirt virtual network has the same IP subnet as the desired management network but a different name. It identifies the resulting network-name mismatch and reports that correcting the network definition in the Vagrantfile resolves the problem. ### Source excerpt TL&DR: Badly. The vagrant-libvirt plugin mysteriously crashes when an existing virtual network (with a different libvirt name) uses the same IP subnet as the desired management network. Background: netlab is using the vagrant-libvirt plugin to manage libvirt/KVM virtual machines with Vagrant. As I already have that infrastructure, I use it to start standalone virtual machines (usually to test various Ubuntu releases) on my Linux server. Things work great... until they don't. Here's how I managed to waste half a day chasing imaginary gremlins caused by a simple error. Read more ... ## QEMU Google Summer of Code 2026 project report DevFeed: [QEMU Google Summer of Code 2026 project report]() Original publisher: [Read original article]() Published: 2026-09-15T07:00:00Z Content type: article Language: en Sources: [QEMU]() Topics: [qemu](), [AdventureX 2025](), [Open Source](), [virtual machines](), [x86](), [observability](), [Rust]() Tags: [cpu](), [development](), [google-summer-of-code](), [gsoc](), [internships](), [observability](), [open-source](), [qemu](), [rust]() ### AI overview QEMU's Google Summer of Code 2026 report covers four contributors' open-source projects from May through August, including lazy snapshot loading, x86 Process Context Identifier support in COCONUT-SVSM, and observability support for confidential virtual machines. ### Source excerpt QEMU participated in Google Summer of Code 2026 with 4 contributors working on open source internships from May through August. The contributors gained experience in open source software development working on 12-week projects. ## AAOS SDV - Secure by Design DevFeed: [AAOS SDV - Secure by Design]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-08-24T16:00:31Z Content type: article Language: en Sources: [Android Developers Blog]() Topics: [Android](), [Security](), [virtualization](), [virtual machines](), [SELinux](), [POSIX](), [Processes](), [Google]() Tags: [android](), [android-security](), [article](), [google](), [posix](), [process](), [security](), [selinux](), [virtual-machines](), [virtualization]() ### AI overview This article explains the security design of Android Automotive Operating System for Software Defined Vehicle (AAOS SDV). It describes virtualization for domain isolation, UID-based application and service sandboxing, POSIX capabilities, SELinux deny-by-default enforcement, and Android's vulnerability management and disclosure processes. ### Source excerpt Posted by Markus Vill, Software Engineer, Sean Keys, Security Engineer, and Istvan Nador, Software Engineer, Android Auto At Google, we believe our products should be secure by design, which is why we built the Android Automotive Operating System for Software Defined Vehicle (AAOS SDV) on existing, market-proven platforms, leveraging virtualization technologies like Cuttlefish. While our release announcements focused on the features, this blog post outlines some of the security concepts. Foundation: Domain IsolationVirtualization to isolate co-hosted instances The current trend of consolidating Electronic Control Units (ECUs) into a single chip reduces isolation by running multiple domains side-by-side. While AAOS SDV instances provide internal isolation mechanisms, it is often preferable to run logical domains independently. For instance, a cluster and an infotainment system have distinct requirements. We use virtual machines to run multiple instances in parallel, ensuring that sharing remains explicit and isolation is the default behavior. Inherited Android Security AAOS SDV evolved from Microdroid, a minimalistic Android version optimized for privacy virtual machines (pVM). This lineage provides Android platform engineers with established security features they already know. Process Isolation & Deny by Default AAOS SDV follows Android's User ID (UID)-based isolation model to set up a sandbox for each application. Each service runs in a dedicated process with a unique UID to manage access rights, data directories, and other restrictions. We employ Portable Operating System Interface (POSIX) capabilities to strictly limit operations and pair this with Security-Enhanced Linux (SELinux) to enforce a "deny-by-default" posture. This approach restricts each service to the absolute minimum required, meaning missing configurations block access rather than creating an over-permissive system. We apply this same strategy to our communication permission system, as explained l ## Compiling to intermediate representation: Write yourself a compiler, Part III DevFeed: [Compiling to intermediate representation: Write yourself a compiler, Part III]() Original publisher: [Read original article]() Published: 2026-08-16T22:00:00Z Content type: tutorial Language: en Sources: [Tomasz Nurkiewicz around Java and concurrency]() Topics: [Compiler](), [virtual machines](), [Code](), [WebAssembly](), [Java]() Tags: [assembly](), [bytecode](), [compilation](), [compiler](), [go](), [interpreter](), [ir](), [javascript](), [python](), [virtual-machines](), [webassembly](), [writing-compiler]() ### AI overview This tutorial explains how a small interpreter project evolves into a compiler by emitting intermediate representation (IR). It contrasts interpreted and compiled languages, describes bytecode and virtual machines, and uses Java and WebAssembly examples to show how IR instructions are executed. ### Source excerpt It's time to dive a bit deeper and abandon the naive realm of interpreters. Our tiny little project can finally call itself a compiler. In this part we'll emit so-called intermediate representation instead of just evaluating and running the source code as-is. OK, what does this all mean? ## The Pulse: Bending Spoons' Acquisition Strategy DevFeed: [The Pulse: Bending Spoons' Acquisition Strategy]() Original publisher: [Read original article]() Author: Gergely Orosz Published: 2026-08-05T11:45:13Z Content type: opinion Language: en Sources: [The Pragmatic Engineer]() Topics: [migration](), [Architecture & Design](), [Microservices](), [Java](), [virtual machines](), [Cloud](), [Google Cloud Platform (GCP)](), [legacy application]() Tags: [architecture](), [backend](), [cloud](), [google-cloud](), [java](), [legacy](), [microservices](), [migration](), [performance](), [provisioning](), [virtual-machines]() ### AI overview The article examines Bending Spoons' acquisition strategy, including its announced $1.285 billion cash purchase of Airtable and its approach to operating struggling products with smaller teams. It also describes the company's reported modernization of Evernote from a Java 11 monolith running across 750 manually provisioned virtual machines on Google Cloud to a managed-database and microservices architecture in about six months, with reported improvements in performance, reliability, operating cost, and on-call load. ### Source excerpt In only 5 years, Hopin went from zero to a $7.7B valuation, and back to zero again. Also: Bending Spoons' startup acquisition model. ## Changing Interfaces Connected to netlab Links DevFeed: [Changing Interfaces Connected to netlab Links]() Original publisher: [Read original article]() Published: 2026-03-30T05:27:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Containers](), [virtual machines](), [Cisco]() Tags: [cisco](), [containers](), [interfaces](), [netlab](), [network](), [node](), [virtual-machines]() ### AI overview This article explains how netlab uses interface ifindex values to connect virtual lab interfaces to specific links. It examines how interface names and mappings behave across Ethernet devices, containers, KVM virtual machines, vrnetlab, and Linux processes running in containers. ### Source excerpt Some netlab users want to accurately replicate their physical network's topology in a virtual lab. Ignoring the obvious caveats for a moment, the first hiccup is usually the interface naming. All bets are off if you're using anything but Ethernet in your actual network, but even if you did standardize on Ethernet, the container/VM interface names might not match the physical ones. netlab provided a solution for a long time - you can specify interface ifindex when attaching a node to a link. For example, use the following topology to connect Ethernet3 on R1 to Ethernet6 on R2: Read more ... ## two mechanisms for dynamic type checks DevFeed: [two mechanisms for dynamic type checks]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-02-18T16:21:10Z Content type: tutorial Language: en Sources: [wingolog]() Topics: [virtual machines](), [Inheritance](), [WebAssembly](), [JIT](), [Polymorphism]() Tags: [cardelli](), [cohen](), [dfs](), [display-hack](), [dybvig](), [scheme](), [vitek](), [wasm](), [webassembly]() ### AI overview This technical note explains two mechanisms for dynamic instance type checks in virtual machines with single inheritance. It describes DFS numbering when the type set is fixed and the display hack, based on per-type supertype arrays, when types can be added at run time. ### Source excerpt Today, a very quick note on dynamic instance type checks in virtual machines with single inheritance. The problem is that given an object o whose type is t, you want to check if o actually is of some more specific type u. To my knowledge, there are two sensible ways to implement these type checks. if the set of types is fixed: dfs numbering Consider a set of types T := {t, u, ...} and a set of edges S := {, ...} indicating that t is the direct supertype of u, or ε if u is a top type. S should not contain cycles and is thus a direct acyclic graph rooted at ε. First, compute a pre-order and post-order numbering for each t in the graph by doing a depth-first search over S from ε. Something like this: def visit(t, counter): t.pre_order = counter counter = counter + 1 for u in S[t]: counter = visit(u, counter) t.post_order = counter return counter Then at run-time, when making an object of type t, you arrange to store the type's pre-order number (its tag) in the object itself. To test if the object is of type u, you extract the tag from the object and check if tag-u.pre_order mod 2n < u.post_order-u.pre_order. Two notes, probably obvious but anyway: one, you know the numbering for u at compile-time and so can embed those variables as immediates. Also, if the type has no subtypes, it can be a simple equality check. Note that this approach applies only if the set of types T is fixed. This is the case when statically compiling a WebAssembly module in a system that doesn't allow modules to be instantiated at run-time, like Wastrel. Interestingly, it can also be the case in JIT compilers, when modeling types inside the optimizer. if the set of types is unbounded: the display hack If types may be added to a system at run-time, maintaining a sorted set of type tags may be too much to ask. In that case, the standard solution is something I learned of as the display hack, but whose name is apparently ungooglable. It is described in a 4-page technical note by Norman H. Coh ## DigitalOcean Announces GPU Droplets Accelerated by NVIDIA HGX B300 DevFeed: [DigitalOcean Announces GPU Droplets Accelerated by NVIDIA HGX B300]() Original publisher: [Read original article]() Author: Waverly Swinton Published: 2025-12-15T17:51:51Z Content type: release Language: en Sources: [DigitalOcean]() Topics: [Digital Ocean](), [GPU](), [Blackwell](), [Nvidia](), [virtual machines](), [High-Performance Computing](), [Inference](), [Cloud](), [Generative AI](), [data analytics](), [Multi-GPU](), [long-context]() Tags: [ai](), [blackwell](), [compute](), [digitalocean](), [gpu](), [high-performance-computing](), [inference](), [infrastructure](), [long-context](), [multi-gpu](), [nvidia](), [product-updates](), [real-time]() ### AI overview DigitalOcean announces GPU Droplets accelerated by NVIDIA HGX B300, describing the platform's intended benefits for AI training, inference, generative AI, data analytics, and high-performance computing workloads. ### Source excerpt AI continues to evolve at an unprecedented pace, with new models and demanding workloads pushing the boundaries of what's possible. From complex large language models (LLMs) to intricate scientific simulations, developers and businesses need access to the most powerful and efficient computing infrastructure. At DigitalOcean, we're committed to providing the cutting-edge tools you need to build, deploy, and scale your AI initiatives with simplicity and affordability. That's why we're excited to announce that GPU Droplets accelerated by NVIDIA HGX™ B300 are coming soon to DigitalOcean, marking a significant upgrade to our GPU offerings. Why NVIDIA HGX™ B300? The NVIDIA Blackwell Ultra accelerated computing platform represents a leap forward in AI reasoning. Designed for both training and inference, the NVIDIA HGX B300 offers substantial improvements in computational power, memory bandwidth, and energy efficiency compared to previous generations. The NVIDIA Blackwell architecture at the heart of the HGX B300 is not just about raw power; it's also about efficiency and innovation. With 1.5X more dense Tensor Core FLOPS, enhanced attention performance, and significantly expanded memory, the HGX B300 is optimized for the most demanding AI workloads including generative AI, data analytics, and high-performance computing (HPC). Featuring 7X more AI compute than NVIDIA Hopper platforms, 2.1TB of HBM3e memory, and high-performance networking integration with NVIDIA ConnectX-8 SuperNICs, Blackwell Ultra delivers breakthrough performance on the most complex workloads from agentic systems and reasoning, to real-time video generation. For AI-native enterprises running large reasoning models and long-context workloads, this enables: -Reduced model offloading and improved time-to-first-token -Higher sustained throughput under concurrency -More efficient multi-GPU scaling -Improved tokens-per-second per dollar Unlike GPU capacity providers, DigitalOcean integrates inference-optimized ## Sandbox Your AI Dev Tools: A Practical Guide for VMs and Lima DevFeed: [Sandbox Your AI Dev Tools: A Practical Guide for VMs and Lima]() Original publisher: [Read original article]() Author: Chris Hager Published: 2025-11-25T00:00:00Z Content type: tutorial Language: en Sources: [Chris Hager]() Topics: [AI-assisted coding](), [developer tooling](), [virtual machines](), [sensitive data](), [API keys](), [ssh](), [npm](), [pip]() Tags: [ai-assisted-coding](), [api-keys](), [dev-tools](), [npm](), [python](), [sandbox](), [sensitive-data](), [ssh]() ### AI overview A practical guide to sandboxing AI coding assistants and other development tools in isolated virtual machines using Lima. It explains how isolation helps protect SSH keys, API tokens, credentials, environment variables, and other sensitive data from arbitrary code, scripts, and package installation behavior. ### Source excerpt AI coding assistants, npm, pip, and other development tools can run arbitrary code and scripts on your machine, potentially stealing SSH keys, API tokens, wallet keys, sensitive credentials and other private data without you noticing. This guide shows you how to sandbox these tools in isolated VMs using Lima, so you can experiment and develop freely without putting your sensitive data at risk. Jump straight to the guide, or read on for a bit of personal context. ## ansible-k3s-on-vms updated to Debian 13 (Trixie) DevFeed: [ansible-k3s-on-vms updated to Debian 13 (Trixie)]() Original publisher: [Read original article]() Author: Staf Wagemakers Published: 2025-11-13T04:30:00Z Content type: release Language: en Sources: [stafwag Blog]() Topics: [Ansible](), [k3s](), [Debian](), [Raspberry Pi](), [virtual machines](), [Cloud]() Tags: [ansible](), [changelog](), [cloud](), [cloudinit](), [cluster](), [debian](), [debugging](), [k3s](), [kubernetes](), [linux](), [pi](), [pi-4](), [release](), [virtual-machines]() ### AI overview The article announces updated Ansible roles for provisioning virtual machines and deploying k3s on a Raspberry Pi 4 cluster. The roles were updated for Debian 13 Trixie and include new templates, examples, and fixes across several roles. ### Source excerpt I use the lightweight Kubernetes K3s on a 3-node Raspberry Pi 4 cluster. And created a few ansible roles to provision the virtual machines with cloud image with cloud-init and deploy k3s on it. I updated the roles below to be compatible with the latest Debian release: Debian 13 Trixie. With this release comes a new movie ;-) ## Announcing per-sec billing, new Droplet plans, BYOIP, and NAT gateway to reduce scaling costs DevFeed: [Announcing per-sec billing, new Droplet plans, BYOIP, and NAT gateway to reduce scaling costs]() Original publisher: [Read original article]() Author: Nihar Namjoshi Published: 2025-10-02T08:03:13Z Content type: release Language: en Sources: [DigitalOcean]() Topics: [Digital Ocean](), [Cloud](), [cloud-infrastructure](), [virtual machines](), [VPC](), [CI/CD]() Tags: [ci-cd](), [cloud](), [cloud-infrastructure](), [digitalocean](), [droplets](), [network](), [product-updates](), [virtual-machines](), [vpc]() ### AI overview DigitalOcean announces per-second billing for Droplets, new dedicated Droplet plans, generally available BYOIP, and a VPC NAT Gateway. The updates target more precise cost control, performance upgrades, IP reputation protection, and centralized egress management. ### Source excerpt To help users cut down on cloud spending that's wasted due to over-provisioning and inflexible billing models, we're introducing tools that offer granular control without sacrificing simplicity or cost-effectiveness. We're excited to announce new product updates that offer granular cost control, improved performance, and a clear path to savings. TL;DR DigitalOcean has transitioned to per-second billing for Droplets. Starting from January 1, 2026, you only pay for the exact compute time you use, perfect for slashing costs on ephemeral tasks and CI/CD pipelines. Create Droplets for short-lived workloads. New dedicated Droplet plans are now generally available for a seamless performance upgrade. Visit your DigitalOcean console to create these new Droplets. Bring your own IP is now generally available to protect your IP reputation. Check out our documentation or visit your DigitalOcean console to bring your own ip. VPC NAT gateway is now generally available for centralized egress and static IPs. Join our webinar: Stop the manual struggle of managing NAT instances and bastion hosts or check out our documentation or visit your DigitalOcean console to set up your NAT gateway. Droplets per-second billing slashes costs for ephemeral workloads Traditional hourly billing models for virtual machines have resulted in customers paying for idle time, even for short-lived workloads. Starting from Jan 1, 2026, our billing model transitioned to a per-second basis for Droplets, with a minimum charge of 60 seconds or $0.01, whichever is higher. This new approach aims to optimize cost control by charging for exact usage over a minute, making it simple to get precise billing for your actual usage. For sustained workloads, the monthly cap of 672 hours (24 hours x 28 days) of usage remains in place, ensuring your bill never exceeds the predictable monthly price. Imagine your development team uses a CI/CD pipeline that uses $84/month CPU-Optimized Droplet to run automated tests taking 10 mi ## QEMU version 10.1.0 released DevFeed: [QEMU version 10.1.0 released]() Original publisher: [Read original article]() Published: 2025-08-26T23:25:00Z Content type: release Language: en Sources: [QEMU]() Topics: [qemu](), [version](), [virtualization](), [virtual machines](), [RISC-V](), [cpu](), [Kernel](), [Arm](), [InfiniBand](), [intel](), [GB200]() Tags: [arm](), [cxl](), [gb200](), [intel](), [ipv6](), [kernel](), [kvm](), [migration](), [qemu](), [qemu-10-1](), [rdma](), [release](), [releases](), [risc-v](), [version](), [virtual-machines](), [virtualization](), [x86]() ### AI overview QEMU 10.1.0 has been released with more than 2,700 commits from 226 authors. Highlights include confidential-guest support, live-migration improvements, Windows guest load querying, new ARM and RISC-V capabilities, and expanded KVM and x86 virtualization support. ### Source excerpt We'd like to announce the availability of the QEMU 10.1.0 release. This release contains 2700+ commits from 226 authors. ## Network Digital Twins: Between PowerPoint and Reality DevFeed: [Network Digital Twins: Between PowerPoint and Reality]() Original publisher: [Read original article]() Published: 2025-06-19T07:16:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Network](), [networking](), [virtual machines](), [virtualization](), [Hardware](), [cpu]() Tags: [automation](), [cpu](), [examples](), [hardware](), [network](), [networking](), [virtual-machines](), [virtualization]() ### AI overview The article discusses why networking digital twins have struggled to move beyond demonstrations. It identifies limitations involving supported interface technologies, interface-name mapping, chassis and line-card modeling, interface counts, resource requirements, clustered deployment, and the fidelity of virtual data-plane behavior. ### Source excerpt A Network Artist left an interesting remark on one of my blog posts: It's kind of confusing sometimes to see the digital twin (being a really good idea) never really take off. His remark prompted me to resurface a two-year-old draft listing a bunch of minor annoyances that make Networking Digital Twins more of a PowerPoint project than a reality. Read more ... ## ArubaCX VXLAN Routing Packets Have Invalid Lengths DevFeed: [ArubaCX VXLAN Routing Packets Have Invalid Lengths]() Original publisher: [Read original article]() Published: 2025-06-12T05:08:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [VXLAN](), [networking](), [Linux](), [virtual machines]() Tags: [capture](), [ethernet](), [linux](), [netlab](), [tailscale](), [virtual-machines](), [vxlan]() ### AI overview A netlab IRB test exposed that VXLAN packets generated by ArubaCX's routing process reported IP and UDP lengths four bytes larger than the actual packet. The article uses packet captures to trace the issue to a VLAN tag removed during software VXLAN encapsulation without a corresponding length adjustment. ### Source excerpt This blog post describes yet another bizarre example of how reliable digital twins are, but don't worry; they all work great in PowerPoint. After "fixing" the integration tests to deal with ArubaCX's notion of VXLAN VNI having 16 bits, the bridging test worked, but the IRB tests kept failing. In the IRB test, the lab has two layer-3 switches. Each of them should be able to bridge within a VLAN/VXLAN segment and route across the segments. Read more ... ## Capturing Traffic in Virtual Networking Labs DevFeed: [Capturing Traffic in Virtual Networking Labs]() Original publisher: [Read original article]() Published: 2025-03-04T06:43:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Linux](), [qemu](), [virtual machines](), [Containers](), [Docker]() Tags: [capture](), [container](), [containers](), [docker](), [lan](), [linux](), [netlab](), [networking](), [qemu](), [virtual-machines](), [virtualization]() ### AI overview A tutorial on capturing traffic in virtual networking labs. It explains how to capture traffic from Linux bridges and QEMU-connected virtual machines, use netlab capture as a wrapper around virsh, brctl, and tcpdump, and approach traffic capture for containers attached to Docker networks or Linux bridges. ### Source excerpt When I announced the Stub Networks in Virtual Labs blog post on LinkedIn, I claimed it was the last chapter in the "links in virtual labs" saga. I was wrong; here comes the fourth part of the virtual links trilogy - capturing "on the wire" traffic in virtual networking labs. While network devices provide traffic capture capabilities (usually tcpdump in disguise generating a .pcap file), it's often better to capture the traffic outside of the device to see what the root cause of the problems you're experiencing might be. Read more ... ## Taming A Voracious Rust Proxy DevFeed: [Taming A Voracious Rust Proxy]() Original publisher: [Read original article]() Published: 2025-02-26T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [Rust](), [fly](), [tracing](), [incident](), [Tokio](), [Containers](), [Network](), [virtual machines](), [HTTP](), [Monitoring](), [cpu]() Tags: [async](), [cdn](), [close-to-users](), [containers](), [cpu](), [deploy-app-servers](), [docker](), [elixir](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [http](), [i](), [incident](), [monitoring](), [network](), [networking](), [postgresql-clusters](), [rust](), [servers](), [tokio](), [tracing](), [virtual-machines]() ### AI overview The article investigates a recurring CPU and HTTP-error incident affecting Fly.io edge proxies. Profiling reveals unexpectedly high overhead in Rust tracing's Subscriber while the proxy handles largely idle asynchronous work, leading into a review of async Rust futures and Tokio execution. ### Source excerpt Here's a fun bug. The basic idea of our service is that we run containers for our users, as hardware-isolated virtual machines (Fly Machines), on hardware we own around the world. What makes that interesting is that we also connect every Fly Machine to a global Anycast network. If your app is running in Hong Kong and Dallas, and a request for it arrives in Singapore, we'll route it to HKG. Our own hardware fleet is roughly divided into two kinds of servers: edges, which receive incoming requests from the Internet, and workers, which run Fly Machines. Edges exist almost solely to run a Rust program called fly-proxy, the router at the heart of our Anycast network. So: a week or so ago, we flag an incident. Lots of things generate incidents: synthetic monitoring failures, metric thresholds, health check failures. In this case two edge tripwires tripped: elevated fly-proxy HTTP errors, and skyrocketing CPU utilization, on a couple hosts in IAD. Our incident process is pretty ironed out at this point. We created an incident channel (we ❤ Rootly for this, seriously check out Rootly, an infra MVP here for years now), and incident responders quickly concluded that, while something hinky was definitely going on, the platform was fine. We have a lot of edges, and we've also recently converted many of our edge servers to significantly beefier hardware. Bouncing fly-proxy clears the problem up on an affected proxy. But this wouldn't be much of an interesting story if the problem didn't later come back. So, for some number of hours, we're in an annoying steady-state of getting paged and bouncing proxies. While this is happening, Pavel, on our proxy team, pulls a profile from an angry proxy. So, this is fuckin' weird: a huge chunk of the profile is dominated by Rust tracing's Subscriber. But that doesn't make sense. The entire point of Rust tracing, which generates fine-grained span records for program activity, is that entering and exiting a span is very, very fast. If the mere ## Stub Networks in Virtual Labs DevFeed: [Stub Networks in Virtual Labs]() Original publisher: [Read original article]() Published: 2025-02-25T06:55:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Containers](), [virtual machines](), [qemu]() Tags: [containers](), [netlab](), [networking](), [networks](), [qemu](), [virtual-machines](), [virtualization]() ### AI overview This article explains how to create stub network segments connected to a single router or switch in virtual labs. It discusses QEMU UDP tunnels and Linux dummy interfaces in containerlab, including compatibility issues with VyOS and Arista cEOS. ### Source excerpt The previous blog posts described how virtualization products create LAN segments and point-to-point links. However, sometimes we need stub segments - segments connected to a single router or switch - because we don't want to waste resources creating hosts attached to a network device, but would still prefer a more realistic mechanism than static routes to inject IP subnets into routing protocols. Read more ... ## How to run Firecracker without KVM on cloud VMs DevFeed: [How to run Firecracker without KVM on cloud VMs]() Original publisher: [Read original article]() Author: Alex Ellis Published: 2025-02-12T09:05:21Z Content type: tutorial Language: en Sources: [Alex Ellis' Blog]() Topics: [Firecracker](), [virtualization](), [virtual machines](), [Cloud](), [Amazon Web Services](), [Amazon EC2]() Tags: [aws](), [bare-metal](), [cloud](), [ec2](), [firecracker](), [github-actions](), [kvm](), [qemu](), [virtual-machines](), [virtualization]() ### AI overview This tutorial introduces a way to run microVMs on cloud virtual machines without KVM, using the PVM virtualization framework. It explains the limitations of nested virtualization and compares the cost of AWS bare-metal EC2 with alternatives. ### Source excerpt MicroVMs need bare-metal or nested virtualisation with /dev/kvm. But what if that's not available? The PVM virtualisation framework may be the answer. ## Point-to-Point Links in Virtual Labs DevFeed: [Point-to-Point Links in Virtual Labs]() Original publisher: [Read original article]() Published: 2025-02-12T06:55:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [virtual machines](), [qemu](), [Vagrant](), [Containers](), [Linux](), [Command-line interface]() Tags: [blog-post](), [cli](), [container-networking](), [containers](), [linux](), [netlab](), [networking](), [qemu](), [vagrant](), [virtual-machines](), [virtualization]() ### AI overview This article explains how virtual labs connect virtual machines and Linux containers. It covers UDP tunnels used by KVM/QEMU/libvirt/Vagrant, point-to-point vEth links created by containerlab, and the packet-capture limitations of UDP tunnels. ### Source excerpt In the previous blog post, I described the usual mechanisms used to connect virtual machines or containers in a virtual lab, and the drawbacks of using Linux bridges to connect virtual network devices. In this blog post, we'll see how KVM/QEMU/libvirt/Vagrant use UDP tunnels to connect virtual machines, and how containerlab creates point-to-point vEth links between Linux containers. Read more ... ## Waiting for Network Device Interfaces During netlab Provisioning DevFeed: [Waiting for Network Device Interfaces During netlab Provisioning]() Original publisher: [Read original article]() Published: 2025-02-05T06:59:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Network](), [virtual machines](), [Containers](), [Vagrant](), [Ansible](), [qemu](), [ssh]() Tags: [ansible](), [cisco](), [containers](), [netlab](), [network](), [qemu](), [ssh](), [vagrant](), [virtual-machines]() ### AI overview The article explains why netlab must wait for network device interfaces to become operational after virtual machines and containers start. It describes readiness checks for SSH and interfaces, including differences in Cisco Nexus OS and Junos, and outlines how Ansible profiling is used to measure startup delays. ### Source excerpt Once a virtual machine running a network operating system boots, you'd expect its data-plane interfaces to be operational, right? Some vendors disagree. It takes over a minute for some network operating systems to figure out they have this thing called interfaces.1 I would love to figure out what takes them so long (a minute is an eternity on modern CPUs), but I guess we'll never know. Behind the Scenes netlab uses two device provisioning mechanisms: it can start virtual machines with Vagrant or containers with containerlab. Some of those containers might use KVM/QEMU to run a hidden virtual machine (see also: RFC 1925 rule 6a). Read more ... ## Links in Virtual Labs DevFeed: [Links in Virtual Labs]() Original publisher: [Read original article]() Published: 2025-02-03T07:27:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [virtualization](), [networking](), [Linux](), [virtual machines](), [Containers](), [Vagrant]() Tags: [containers](), [ethernet](), [links](), [linux](), [netlab](), [network](), [networks](), [vagrant](), [virtual-machines](), [virtualization]() ### AI overview This article explains how physical network links are represented in virtual labs. It examines virtual bridge switches, Linux bridges, Vagrant and libvirt networks, tap interfaces, and the veth-pair method for connecting containers to Linux bridges. ### Source excerpt There are three major ways to connect network devices in the physical world: Point-to-point links between devices (usually using some variant of Ethernet) Multi-access layer-1 networks running some IEEE 802.x encapsulation on top of that (GPON, WiFi, Ethernet hubs) Multi-access switched layer-2 network (dumb switches, hopefully running some STP variant) Implementing these connections in virtual labs is a bit harder than one might think, as all virtualization solutions assume you plan to run virtual servers connected to Ethernet segments. Read more ... ## How Does Netlab Deal with Server Reboots? DevFeed: [How Does Netlab Deal with Server Reboots?]() Original publisher: [Read original article]() Published: 2024-10-24T06:15:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [Command-line interface](), [Orchestration](), [Vagrant](), [virtual machines](), [Containers](), [Linux]() Tags: [cleanup](), [cli](), [config](), [containers](), [linux](), [netlab](), [orchestration](), [server](), [vagrant](), [virtual-machines]() ### AI overview The article explains that netlab does not automatically recover labs after server reboots, power failures, or crashes because it runs as a CLI rather than a boot-time service. It describes clearing stale locks, restarting virtual-machine labs with snapshot and no-config options, and the more limited recovery options for containers. ### Source excerpt Now and then, someone asks how netlab deals with reboots (or power failures or crashes) of the server it's running on. TL&DR: It doesn't. However... netlab is a CLI command that acts as an umbrella orchestration layer for Vagrant and Containerlab. It does not run as a cron job, init script, or service and thus cannot be invoked when a server is booted. Read more ... ## One-Arm Hub-and-Spoke VPN with MPLS/VPN DevFeed: [One-Arm Hub-and-Spoke VPN with MPLS/VPN]() Original publisher: [Read original article]() Published: 2024-09-24T06:15:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [MPLS VPN](), [Virtual Private Network](), [Network](), [Cisco](), [evpn](), [Routing (disambiguation)](), [virtual machines](), [Containers](), [Ethernet]() Tags: [bgp](), [cisco](), [containers](), [design](), [ethernet](), [evpn](), [mpls-vpn](), [netlab](), [network](), [ospf](), [routing](), [virtual-machines](), [vpn]() ### AI overview This tutorial explains how to build a one-arm hub-and-spoke VPN using MPLS/VPN. It describes a routing approach using common-services VRFs and a default route advertised by the hub, with examples involving Cisco IOS and FRRouting devices. ### Source excerpt All our previous designs of the hub-and-spoke VPN (single PE, EVPN) used two VRFs for the hub device (ingress VRF and egress VRF). Is it possible to build a one-arm hub-and-spoke VPN where the hub device exchanges traffic with the PE router over a single link? TL&DR: Yes, but only on some devices (for example, Cisco IOS or FRRouting) when using MPLS transport. Here's a high-level diagram of what we'd like to achieve: Read more ... [Next page]()