Open Nebula: Live VM Migration Between ARM Edge Nodes with OpenNebula

Name: Open Nebula: Live VM Migration Between ARM Edge Nodes with OpenNebula
Uploaded: 2026-08-11T09:08:45-04:00
Duration: 4 min 25 s
Description: In this screencast, we walk through a live VM migration between two ARM-based edge nodes managed by OpenNebula 7.2. The nodes are two Raspberry Pi 5 boards, both running KVM with native ARM64 support and connected to a shared system datastore. The goal...

Open Nebula

08/11/2026

0 (0%)

Report Like Favorite

Transcript

screencast. In this screencast, we will walk through the live virtual machine migration between two ARM-based edge nodes managed by OpenAbula 7.2. The nodes are represented by two Raspberry Pi 5 boards, both running KVM with native ARM64 support, both attached to a shared system datastore. The main goal is to show that a workload can move between those nodes while it is running, without losing its IP address, network connections, and without resetting the kernel up-to-encounter. The ARM-based edge environments typically struggle with resource constraints defined by MODIS CPU capabilities, tight memory limits, and connectivity with restricted bandwidth. Despite this profile of MODIS hardware and restricted uplinks, workloads must remain mobile to accommodate hardware failures, load balancing, or scheduled maintenance. OpenAbula 7.2 addresses these requirements by supporting lightweight KVM virtualization and native ARM64 support. The solution utilizes a shared catalog of ARM images and cache-aware migration techniques leveraging distributed image caching and QCode2 deltas to minimize data transfer between nodes. We demonstrate the effectiveness of this architecture by performing the live migration of the virtual machine between two Raspberry Pi 5 nodes orchestrated by a single OpenAbula frontend. The cluster is intentionally minimal. It consists of two Raspberry Pi 5 boards acting as full KVM hypervisors, registered as regular hosts in OpenAbula. Both share the common system datastore over the network so KVM can perform the true live migration. Because the disk image is already in place on the destination, only the guest memory needs to be moved. A single OpenAbula frontend sits above the two nodes and handles all orchestration. The migration is broken down into four observable steps that we will walk through one at a time. Step 1 consists of deploying a fresh virtual machine on the node A. Step 2 is to confirm that it is running and reachable. Step 3 is to perform the live migration to the node B. And the final step is to verify that the workload is running on the node B with minimal disruption. We sign in to Sunstone as the one-admin user and navigate to the infrastructure hosts page. Three KVM hosts are registered. The two relevant ones for this demonstration are named Raspberry Pi 5 and Raspberry Pi 5-2. Both are members of the Edge ARM cluster, both reporting the Arch64 architecture. The cluster currently has two virtual machines running. We need to add the third one by picking the Eurocopilot ARM template, a tiny 512 MB image and press finish. The new virtual machine is scheduled on the Raspberry Pi-2 node, also known as Pi-5 node A on the Barcelona Edge. It runs with one virtual CPU and 1 GB of memory, a deliberately small footprint that proves the point about resource-constrained Edge. Being tiny it fastly reaches the running state. By opening the detailed view of the host we can clearly see the indicators of an ARM Edge node, Arch64 architecture, KVM hypervisor, the full Cortex-A76 family CPU and OpenABLO 7.2, the release that brought the ARM64 support. Inside the guest, the terminal-based status panel refreshes once per second showing the current host, the kernel uptime in monotonic seconds and the round-trip times to the gateway and to the public network. From the VM Actions drop-down menu we must select the Migrate Live option. Select the destination node. In our case it is named Raspberry Pi-5. Then leave the datastore unchanged and press finish to kickstart the process. The virtual machine enters the Migrate state. QEMU streams the guest's GB of memory from the node A to the node B while the guest keeps running. The kernel uptime counter in the terminal keeps ticking up without reboot and without getting Secure Shell disconnected. A few moments later the terminal-based status panel reports the changes. The running host changes to Pi-5 node B in Madrid and the kernel uptime climbs past 162 seconds. The status of the virtual machine in Sunstone returns back to running. This screencast was developed in the scope of EAPS-ISIS project. Thank you for watching and see you in the next screencast.

TL;DR

OpenNebula 7.2 enables seamless live VM migration between ARM-based edge nodes using Raspberry Pi 5 boards as KVM hypervisors with native ARM64 support
The migration preserves network connections, IP configuration, and kernel uptime by leveraging shared datastores and cache-aware techniques that minimize bandwidth requirements
The demonstration proves workload mobility is achievable even on resource-constrained edge hardware through lightweight virtualization and distributed image caching

Summary

This technical demonstration showcases OpenNebula 7.2's capability to perform live virtual machine migration between resource-constrained ARM-based edge nodes. Using two Raspberry Pi 5 boards as KVM hypervisors with native ARM64 support, the screencast walks through a complete migration workflow that preserves network connectivity, IP addressing, and kernel uptime throughout the process. The demonstration addresses a critical challenge in edge computing environments where modest CPU capabilities, tight memory limits, and restricted bandwidth typically complicate workload mobility. OpenNebula's solution leverages shared system datastores, distributed image caching, and QCOW2 delta techniques to minimize data transfer during migration. The four-step process—deploying a VM on node A, confirming operation, migrating to node B, and verifying continuity—proves that even minimal hardware configurations can support enterprise-grade workload portability when orchestrated through OpenNebula's lightweight virtualization architecture. The demonstration uses a deliberately small VM footprint (1 vCPU, 1GB RAM, 512MB image) to emphasize the platform's efficiency in edge scenarios where hardware resources are at a premium.

Chapters

0:00 - Introduction and Architecture Overview
1:19 - Cluster Configuration and Components
1:46 - Four-Step Migration Process
2:10 - Live Migration Demonstration

Key Quotes

0:26 "The main goal is to show that a workload can move between those nodes while it is running, without losing its IP address, network connections, and without resetting the kernel up-to-encounter."
0:51 "OpenAbula 7.2 addresses these requirements by supporting lightweight KVM virtualization and native ARM64 support."
1:35 "Because the disk image is already in place on the destination, only the guest memory needs to be moved."

FAQ

What hardware requirements are needed for ARM-based edge node migration with OpenNebula?

The demonstration uses Raspberry Pi 5 boards running KVM with native ARM64 support, connected to a shared system datastore over the network. Both nodes must be registered as regular hosts in OpenNebula and share access to common storage to enable live migration without moving disk images.

Categories:

Tags:

Show more Show less

TL;DR

Summary

Chapters

Key Quotes

FAQ

Bridging the SaaS Protection Gap: Preventing Data Loss and AI Missteps

The Automation Escalation: Discovering the AI-Driven Underground Revolution

Invisible Data: Understanding What You Can't Safeguard