microsrv:~$
Console

All posts

eBPF Networking in microsrv: Preserving IPs, Sockets, and Gateways During VM Migration

Published

+----------------------------------------------------------------------------+
| MICROSRV eBPF ARCHITECTURE: INDEPENDENT NETWORK IDENTITY                   |
+----------------------------------------------------------------------------+
|                                                                            |
|  [ENTRY POINTS]      SSH Gateway                 HTTPS / SNI API Gateway   |
|                      (ssh <vm>@microsrv.ru)   (https://<vm>.microsrv.ru)     |
|                             |                            |                 |
|                             +--------------+-------------+                 |
|                                            |                               |
|  [eBPF DATA PLANE]                         v                               |
|                      +------------------------------------------+          |
|                      |   eBPF MAPS: DYNAMIC ROUTE REBINDING     |          |
|                      +------------------------------------------+          |
|                             |                            |                 |
|  [PRIVATE VPC]              v                            v                 |
|                     +---------------+            +---------------+         |
|                     | VM A (10.42)  |            | VM B (10.42)  |         |
|                     +---------------+            +---------------+         |
|                                                          |                 |
|  [PHYSICAL HOST]    Host-17 (Evicting)    ===>   Host-42 (Available Spot)  |
|                                                                            |
|  [NETWORK STATUS]   Private IP: PRESERVED | Domain: ACTIVE   | TCP: ACTIVE  |
|                                                                            |
+----------------------------------------------------------------------------+

A virtual machine can move to a new physical server, but its network identity must remain unshakable.

In traditional clouds, migrating an interruptible virtual machine or restarting it on a new host almost always causes a network incident: internal IP addresses drift, established TCP connections break, and external clients lose access until DNS records and firewall rules update.

The microsrv platform solves this challenge directly inside the kernel. An eBPF-powered network layer decouples a VM’s IP address, gateway names, and open sockets from physical hardware. While the orchestrator live-migrates memory and processes, eBPF instantly rebinds network flows to the target host — completely transparently to the application and its users.

Here is a breakdown of how microsrv’s network architecture is designed, what capabilities ship out of the box, and why it eliminates the need for custom reconnection logic in your codebase.


1. The problem with traditional networking during migration

When a virtual machine changes physical hosts — whether for scheduled maintenance or due to a Spot instance eviction notice from the cloud provider — applications face a series of network disruptions:

  1. Internal IP drift. If a VM receives a new local IP on restart, firewall rules, access control lists (ACLs), and configurations in peer services break.
  2. Broken long-lived TCP sessions. Active SSH connections, database replication streams, WebSocket channels, and long-running HTTP requests fail immediately.
  3. DNS propagation delays. Even when using domain names, clients continue sending traffic to the old IP address due to DNS caching (TTL).
  4. Public IP lock-in. Assigning a public IP directly to a VM’s network interface ties the workload to a specific physical rack and increases infrastructure costs.

To work around these constraints, developers are forced to build complex application logic: exponential backoff reconnects, external load balancers, and custom failover scripts. microsrv’s eBPF data plane handles these requirements at the platform level.


2. How eBPF networking works in microsrv

eBPF (Extended Berkeley Packet Filter) is a Linux kernel technology that executes sandboxed packet-processing code directly inside the network stack without user-space context switches.

In microsrv, eBPF acts as a virtual data plane. The foundational design principle is straightforward:

Network identity (IP addresses, domain names, open sockets) belongs to the guest virtual machine, not to the server hosting it.

When the orchestrator performs a live migration from one Spot host to another:

  • The VM’s network stack and socket table migrate alongside RAM to the new target host.
  • eBPF programs atomically update routing maps (eBPF Maps) to redirect ingress and egress packets to the new physical node.
  • Traffic resumes at the target node instantly without dropping established TCP connections.

3. Core capabilities for engineering teams

Isolated Virtual Private Clouds (VPC)

All virtual machines belonging to a project are grouped into an isolated Virtual Private Cloud (VPC). They communicate using stable private IP addresses without routing traffic through the public internet.

Each VM receives a fixed private IP (e.g., 10.42.0.5) that persists across its entire lifecycle, regardless of how many times it migrates between physical hosts.

Kernel-level Anti-Spoofing

Packet authentication occurs directly in the kernel on the VM’s virtual interface. A guest VM cannot transmit packets using an unauthorized IP or MAC address. This provides strict multi-tenant isolation out of the box without requiring manual iptables configuration inside the guest OS.

Secure Outbound Internet Access (NAT)

Virtual machines frequently need outbound access to download dependencies, query third-party APIs, or push metrics. In microsrv, egress traffic flows through a transparent NAT gateway.

VMs enjoy full outbound internet access while maintaining no direct public IP address, keeping them protected from external port scans and automated attacks.

Unified SSH Access Gateway

Connecting to virtual machines via SSH does not require exposing port 22 to the public internet or purchasing public IP addresses. Access is managed through a unified gateway:

ssh -A <vm>@app.microsrv.ru

The gateway verifies the user’s SSH keys and proxies the connection directly to the target VM inside the VPC. The SSH address remains identical across all migrations.

Built-in L7/L4 API Gateway

To publish web applications and services externally, microsrv includes an API gateway supporting HTTPS and TLS/SNI routing:

  • HTTPS Routing: Requests route automatically to domain names such as <vm>.app.microsrv.ru.
  • TCP / TLS-SNI Routing: Enables secure exposure for non-HTTP services (such as PostgreSQL or MySQL databases):
    psql "host=<vm>.app.microsrv.ru sslmode=require"
  • Automated TLS Certificates: The gateway handles encryption and TLS certificate lifecycle management automatically.

4. Preserving TCP sessions during live migration

The most critical requirement during migration is preserving open network sockets. Dropping active network sessions during memory transfer causes clients to receive Connection Reset by Peer errors.

microsrv’s eBPF layer synchronizes routing state across the migration boundary:

  1. During transfer: Packets are briefly buffered or redirected by eBPF programs to the destination node.
  2. On completion: eBPF maps across all nodes update atomically.
  3. Result: Active SSH terminals, WebSocket streams, and ongoing database transactions continue seamlessly without disconnecting.

Important distinction: Zero-downtime session persistence applies during graceful live migrations (planned relocations or standard Spot eviction notices). In the event of an unannounced physical hardware failure (such as a host kernel panic or power loss), the platform automatically restarts the VM from its replicated disk snapshot.


5. Key benefits for infrastructure operations

  • Zero networking overhead. No need to deploy and manage complex external load balancers, Service Meshes, or DNS re-registration scripts.
  • Code transparency. Applications run in a standard Linux environment without requiring specialized SDKs or custom network drivers.
  • Predictable Spot compute. Achieving about 40% cost savings on cloud infrastructure no longer means accepting frequent socket drops or network instability.
  • Secure by default. Eliminating public IPs on VMs and enforcing kernel anti-spoofing creates a hardened perimeter by default.

6. A unified platform: Memory, storage, and networking

The eBPF network layer completes microsrv’s three pillars of reliability:

  1. The Orchestrator preserves RAM and running application processes.
  2. Replicated Storage preserves disk volumes and file system state.
  3. eBPF Networking preserves IP addresses, routes, and open sockets.

Together, these layers transform volatile, low-cost cloud capacity into resilient virtual machines operating without downtime or data loss.

Run virtual machines for about 40% less than standard cloud rates

microsrv automatically manages interruptible cloud capacity by live-migrating VMs before a host shuts down, while preserving disks, IP addresses, and active connections.

Go to consoleAsk a question