Skip to content
Open access

Xtream: A Production-Level VM Cross-Cloud Disk Migration System with Stripe-Oriented Prefetching

Aug 2026 · ACM Transactions on Architecture and Code Optimization (TACO) · 0 citations · 62 references

TL;DR

Xtream designs a mechanism for collaborative cold and hot data migration to ensure timely responses to VM I/O requests and identifies a macro-level locality pattern, characterized as multi-stripe disk access pattern, and develops a stripe-oriented prefetching algorithm in Xtream to improve I/O hit rate.

Abstract

Virtual machine (VM) cross-cloud migration refers to the transfer of VMs between different cloud environments, enabling users to deploy their business with greater flexibility. However, VM cross-cloud migration faces many challenges in production due to the high latency and limited bandwidth of cross-cloud networks. These challenges are pronounced in disk migrations, where poor I/O performance persists and significantly constrains the migration process, even leads to migration failures. This drives the demand for VM migration drills, but existing solutions fail to effectively address it. We present Xtream, a production-level cross-cloud disk streaming migration system. By analyzing the business disk I/O patterns, we identify a macro-level locality pattern, characterized as multi-stripe disk access pattern, and develop a stripe-oriented prefetching algorithm in Xtream to improve I/O hit rate. Xtream designs a mechanism for collaborative cold and hot data migration to ensure timely responses to VM I/O requests. The evaluation demonstrates that Xtream reduces I/O latency by 88.2%, shortens cross-cloud VM startup time by 77.7%, and maintains an over 95% disk hit rate during migration, compared to the state-of-the-art streaming migration. In production, Xtream completes cross-cloud VM drills in 7–22 minutes depending on configuration, significantly reducing migration risks.

Read PDF

Similar papers

Preprint Aug 2026

Offering Microsecond-Scale Cross-VM Core Elasticity on Colocated Lightweight Virtual Machines

Serverless platforms commonly colocate many diverse workloads, each in a fast-booting, memory-lean virtual machine (VM), to improve deployment density. Overprovisioning each VM for its peak protects tail latency during traffic bursts but hurts density; maintaining high density while effectively protecting tail latency requires the infrastructure to be able to shift physical cores, at a microsecond timescale, to whichever latency-sensitive VM is bursting and reclaim them as the burst subsides. No VM substrate delivers this: conventional VMs resize a guest's cores only through a millisecond-scale vCPU hot-plug path, Firecracker fixes a VM's core count at boot, and the ultralight VMs that boot fastest drop multicore execution entirely. We present HyperFlux, a commodity-KVM ultralight VM substrate that makes a VM's parallelism width (the number of physical cores backing it) elastic at runtime. We show that HyperFlux can move a core across VMs in merely 13$\mu$s, even when forcibly reclaiming it from a busy donor, orders of magnitude faster than vCPU hot-plug. A HyperFlux VM incurs only a 3.2MB memory footprint and can cold-boot in 1.37ms, on par with the fastest-booting ultralight VMs, while uniquely supporting multicore parallelism. Under colocation, it can reduce high-priority VMs'tail latency by up to 10x under high load compared to static core-sharing with Firecracker and Cloud Hypervisor, and deliver a lower and more stable tail latency compared to using cgroup and vCPU hot-plug under changing load bursts.

Yibo Yan, Seo Jin Park · 1 citation
Jul 2026

Isolation Failure From Shared Storage: Characterizing and Exploiting Page-Cache SCA Leakage Across Containers and VMs

Modern cloud platforms increasingly combine strong software isolation mechanisms with shared hardware resources to improve performance and resource efficiency. Conventional containers do this by sharing the host kernel directly, whereas sandboxed runtimes (e.g., gVisor) and VM-based runtimes (e.g., Kata, QEMU/KVM) provide progressively stronger isolation. In all cases, when tenants access host-backed filesystem state, the host page cache can remain shared and observable. Although OS-managed, this page-cache channel forms an OS-mediated microarchitectural timing side channel whose signal is shaped by the processor microarchitecture, memory and storage hierarchies, and virtualization mechanisms. We thus investigate whether unprivileged timing measurements can reveal page-cache residency across these isolation boundaries. Our evaluation covers Docker; gVisor with systrap and KVM; Kata Containers using QEMU and Cloud Hypervisor with shared host filesystems; Kata using QEMU, Cloud Hypervisor, and Firecracker with block-device-backed storage; and QEMU/KVM virtual machines under multiple host cache policies. Our results show that the timing signal persists whenever the I/O path exposes shared, host-cacheable file-backed objects, including under OverlayFS layers, virtio-fs exports, and loop-backed block devices. However, direct I/O and dedicated block devices substantially attenuate or eliminate the signal. Virtualization therefore reshapes leakage through added latency and algorithmic noise but does not remove the underlying dependence on shared hardware and cache state. We showcase this through a case study in which we recover coarse-grained activity from a WordPress deployment backed by MySQL. These results place page-cache attacks within the broader class of OS-mediated microarchitectural timing channels and motivate coordinated hardware, virtualization, and OS support for timing isolation.

Alon Abudraham, Xing-Yu Chen, Itamar Levi et al. · 0 citations
Preprint Sep 2026

Gutenberg: Taming Latency-Critical Cloud Services with Near-Data-Processing

Latency-critical cloud services place growing pressure on memory while requiring isolation, fairness, and predictable QoS. Near-data processing (NDP) reduces data movement by executing requests close to memory, and prior systems further improve locality through caching and replication. However, writes make replica maintenance expensive, while uneven compute and memory traffic can overload a few NDP units and increase tail latency. Existing throughput-oriented schedulers do not fully address these challenges for co-located cloud services. We present Gutenberg, a CPU+NDP for mutable, latency-critical cloud services. Gutenberg stages subpage updates in a CPU-resident delta buffer, allowing hot writable pages to remain replicated without eager full-page synchronization. It also adopts CPU helper cores to assist request execution when NDP execution or replica maintenance becomes costly. An online controller jointly decides page placement, replication, CPU/NDP execution, and routing using access patterns, queue pressure, and feedback from prior decisions. The system further enforces isolation and fair resource allocation across services. We also model-check CPU--NDP coordination protocol for correctness. We evaluate on TailBench using ZSim with Ramulator-calibrated memory timing. Across evaluated services, Gutenberg outperforms prior systems, reducing average and p99 latency by up to 80.4% and 85.8%. It also improves isolation and fairness while adapting to changing workload behaviors.

Qi Lin, Phillip B. Gibbons, Jovan Stojkovic et al. · 0 citations
Open access 2018

Performance of Memory Virtualization Using Hybrid Live Migration of Virtual Machines

 Abstract —Today, Infrastructure-as-a-service providers are trying to minimize the cost of data center operations, while maintaining the Service Level Agreements. This can be achieved by one of the advanced state-of-the-art services of virtualization - the live migration capability. Live migration is defined as the process of transferring an active virtual machine from one physical machine to another without any disconnection. This is achieved by transferring all of the encapsulated states of the VM from one host to another. It has become an essential tool for efficient management of resources in a data center by enabling server consolidation and load balancing. There are two classical migration techniques, namely - pre-copy and post-copy, which employ different memory transfer mechanism during the offloading of a VM. In this paper, we propose a novel hybrid live migration technique by combining the existing pre-copy and post-copy approaches. Compare to its counterparts, our hybrid technique is a fast, efficient and a reliable migration technique.

P. Gangadhar · 0 citations
Book Open access Sep 2026

Speeding up FaaS Warm Starts with Memory Restoration Templates

Function-as-a-Service (FaaS) is a cloud-native model where small pieces of application logic execute as isolated functions within virtual machines (VMs). Cloud Service Providers (CSPs) aim to maximize the number of VMs per system. However, idle VMs, i.e., VMs without active functions, continue to consume memory, limiting overall VM density. Rather than using prior disk-based snapshotting solutions to reduce memory usage, we propose to place the pages of an idle VM in a compressed memory pool. Doing so, however, incurs high execution latency upon new invocations due to page decompression during on-demand page faults. To address this, we propose MRT. MRT generates memory restoration templates from the learned sequence of pages that incur page faults during a warm start and uses them to bulk-restore pages using Intel's In-Memory Analytics Accelerator (IAA), avoiding costly on-demand faults. MRT lowers single-instance function execution latency from 2.63× to 1.62× relative to a hot start, eliminating 62% of the overhead that on-demand page-fault-based restoration adds over a hot start. MRT further reduces the memory footprint of an idle FaaS VM instance by 57% (geometric mean) by placing its pages in the compressed memory pool, allowing CSPs to host more active VMs per system. At scale, MRT reduces 95th- and 99th-percentile function execution latency by 70% and 58%, respectively, relative to on-demand IAA decompression.

Aravinda Prasad, S. Subramoney, Sandeep Kumar et al. · 0 citations

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.