Loading…
Topic
11 posts about Virtualization. Every summary links to the original.
See the idea
Bare metal gives engineers direct control over GPU, network, and virtualization layers, but it shifts elasticity and lifecycle work onto the team. This trade-off map shows when that bargain pays off.
Amazon EVS runs VMware Cloud Foundation on AWS bare metal, so the design question becomes where each workload's data lives. This layered diagram shows how vSAN, FSx for ONTAP, and cross-Region DR divide the work.
A five-step how-to for deciding when an AMD Instinct GPU should stay dedicated and when SR-IOV virtual functions, VMs, or sidecar isolation can safely share it.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
The post overviews recent memory management evolutions in Red Hat OpenShift Virtualization, spanning from the Linux kernel to the orchestration planes. Historically, the platform uses a 1:1 memory request mapping, but data shows most VMs use only about 20% of allocated RAM, creating a delta that scales infrastructure with workload definitions rather than demand. Node-level optimizations include free page reporting (FPR), which asynchronously recovers pages freed by the guest OS without forcing allocation like ballooning, and KSM zero pages for guest-agnostic deduplication of zero-filled memory. At the cluster level, Multi-Gen LRU integrated with control groups enables swapping to fast secondary NVMe storage, and a PSI-aware descheduler proactively migrates VMs to relieve memory pressure across nodes. OpenShift Virtualization 4.22 provides an autopilot feature that automates configuration for generally available memory optimizations, while developer preview capabilities require manual opt-in activation by default.
Managing a traditional operating system across multiple hosts often leads to configuration drift, slow updates, and painful rollbacks. Bootable containers solve this by packaging the entire OS as an OCI container image, including the kernel, initrd, bootloader, and applications. Red Hat Enterprise Linux 10 introduced image mode deployment, and the bootc container virtualization kit (bcvk) enables end-to-end testing of these images on a laptop using familiar Podman and libvirt packages. The tool offers three deployment modes: ephemeral for rapid testing, persistent for long-term development, and disk image for creating bootable artifacts. Users build a custom bootc image via a Containerfile with the containers.bootc=1 label, then deploy it identically across virtual and physical infrastructure, reducing environmental drift.
Hosted control planes for Red Hat OpenShift, based on the HyperShift project, decouple the cluster control plane from worker nodes by running control-plane components as pods inside a central management cluster. On bare-metal infrastructure, OpenShift Virtualization provisions worker nodes as virtual machines, enabling live migration and reducing hardware requirements. The article presents a declarative GitOps workflow using Helm templates and an Argo CD ApplicationSet that dynamically generates deployments from tenant-specific YAML configuration files in Git. Prerequisites include a bare-metal management cluster with OpenShift Virtualization, Red Hat Advanced Cluster Management, and OpenShift GitOps, plus networking configured with NMState, Multus CNI, and MetalLB. The approach achieves a “Cluster-as-a-Service” model where provisioning a production-grade cluster requires only a Git push.
Enterprise AI environments are moving from dedicated GPU servers to shared accelerator infrastructure, requiring higher GPU utilization with strong isolation. AMD Instinct MI300X GPUs support hardware-assisted SR-IOV in CPX mode, each exposing eight virtual functions with separate PCI and VRAM allocation. When integrated with Red Hat OpenStack Services on OpenShift, the control plane runs on OpenShift while RHEL compute nodes use EDPM, with Nova scheduling VFs via VFIO PCI passthrough. Validation on an 8-GPU system created 64 VFs, demonstrated 64 VMs with one VF each, and tested up to 32 VFs per VM. BabelStream benchmarks showed approximately 96-99% of bare-metal memory bandwidth, while the testing also identified limitations in GPU peer-to-peer DMA and runtime VF lifecycle.
Modal has launched VM Sandboxes in general availability, providing agents with full Linux VMs accessible via a single flag. The VMs support Docker stacks, local databases, dev servers, and other real-machine features that agents increasingly require, as demonstrated by Ramp’s internal agent driving the entire software development lifecycle. Modal built a custom runtime on the Rust-based Cloud Hypervisor, layering innovations in host filesystems, lazy image loading, memory bursting, and snapshotting to preserve the same APIs and sub-second cold starts as their existing gVisor Sandboxes. Early customers like Linear, Legora, and Snorkel have launched over 20 million VMs, using them for coding sessions, legal agent evaluations, and agent simulations that require multiple containers and real-world environments. Modal recommends using VM Sandboxes when workloads need Docker, FUSE filesystems, or niche kernel features, while gVisor remains the default for compatible workloads.
Rendering a pull request with over a million changed lines and hundreds of threaded comments requires a fundamentally different architecture than a code-only diff. The standard virtualized approach fails because comment heights depend on render-time factors like markdown wrapping, expandable sections, and reply composers. The team split the document’s height into two independent domains: deterministic code geometry and dynamic block geometry for comments. A single idle- and scroll-gated measurement pass, scoped to the viewport, corrects heights without causing reflows mid-scroll. The result is a pull request view where a million-line diff with hundreds of comments opens, scrolls, and behaves like a normally sized pull request.
Migrating from legacy virtualization with flat VLAN-based tenant networks to Red Hat OpenShift Virtualization often requires re-architecting network topology, creating friction. Red Hat OpenShift supports localnet user-defined networks (CUDNs) to preserve existing VLAN infrastructure while modernizing. Red Hat tested localnet CUDNs at scale, successfully managing up to 3,500 localnet CUDNs hosting over 3,500 active virtual machines. OVN-Kubernetes achieved 100% SSH connectivity, near-line-speed data-path performance over 100GbE interfaces without Geneve tunnel overhead, and stable control plane resource usage. Resource peaks reached approximately 5.5 CPU cores per worker node and 10 CPU cores on control plane nodes during bulk creation, then returned to low baselines.
Red Hat OpenShift topologies are mapped to edge-site constraints such as hardware footprint, availability, rack space, power, and workload needs. It is presented as a micro cloud that brings full Kubernetes functionality to server-class edge hardware, with optional virtualization and software-defined storage. Cluster capabilities can be minimized with baselineCapabilitySet: none and selectively enabled later, although added capabilities cannot be removed without reinstalling. Options span single-node OpenShift, which requires 4 vCPUs, 16 GB RAM, and 120 GB storage, two-node designs using fencing or an arbiter, and three-node compact clusters for resilient high availability. Each topology retains shared management and security practices, so selection depends on the physical footprint, failure tolerance, and scale required at the site.
Cursor’s release expands cloud agents and the Cursor harness for longer-running, event-driven software work. Cloud agents can subscribe to pull requests, Slack threads, or scheduled tasks, wake on events, keep goals until completion, and automatically address CI failures and bot comments on pull requests they create. Custom modes pin a selected skill in chat, while /goal supplies a long-lived objective that can be paired with a custom mode or /loop. Subagents can run on separate virtual machines with isolated project copies and clean context, supporting fresh testing or parallel fixes without collisions. Steering improvements let users send follow-ups that wait for the next tool call instead of interrupting an action.
Modal is a platform that runs programs of arithmetic and logic operations on information, making it a computer. It operates on hardware from dozens of cloud providers, building a virtualization layer that aggregates, isolates, and multiplexes demand for increased resource efficiency. Programs run in containers that receive inputs from the container runtime, similar to how a typical computer’s ALU fetches inputs from memory. Information in Modal lives in a tiered storage hierarchy, from container memory to object storage, with caches like page cache and ephemeral disk. Input and output pass through the Modal Input/Output Plane for functions and sandboxes, or the Routing Plane for HTTP servers, with direct Tunnels for extreme performance needs.
Modal also announced several product updates including VM Sandboxes in alpha, lower latency regional routing, and role-based access control. VM Sandboxes, currently in alpha, are a new VM runtime that runs a real Linux kernel, supporting Docker containers and Linux features like eBPF, systemd, cgroups, and custom filesystem mounts for better I/O performance. Regional routing lets Functions run in US West, EU West, or Asia Pacific South instead of default US East with a single setting, lowering latency and keeping data in-region. RBAC is now available for Team and Enterprise plans, with Environments as security boundaries and read-only defaults via Restricted Environments, tied into Audit Logs. Other updates include domain allowlisting, named images, volume subdirectory mounts, readiness probes, configurable snapshot TTLs with a 30-day default, SDK updates, and a partnership with Anthropic for Claude Managed Agents.
The best engineering reads, once a week.
