How ROW‑Based Snapshot Cloning Achieves Seconds‑Level Bulk VM Creation

Business Scenarios Requiring Rapid Bulk VM Creation

In digital business practice, some users need to create large numbers of cloud hosts quickly, such as chip design (hundreds of hosts for compute‑intensive jobs), 3D rendering (large base images for varied rendering tasks), and flash‑sale services (massive concurrent hosts to improve purchase efficiency). The most time‑consuming step in host creation is cloning the virtual machine image, which involves copying multi‑gigabyte images to the storage cluster, often multiplied by three due to replication, leading to unacceptable delays.

Snapshot Clone Technology Selection

COW (Copy‑On‑Write) copies original data blocks to new blocks before modification, storing the original data in the snapshot volume.

ROW (Redirect‑On‑Write) redirects the first write of original data to a reserved snapshot volume, keeping the original data unchanged and making the snapshot volume read‑only. ROW forms a chain of snapshots; each write lands on the latest snapshot volume, improving write performance but increasing merge overhead when many snapshots exist.

Given ROW’s advantage of avoiding the double‑write penalty of COW, the system adopts a ROW‑based internal snapshot and clone mechanism.

Overall Architecture Design

The architecture consists of:

Access: entry service that receives external requests and forwards them to the appropriate storage cluster.

Frigga: image distribution manager that caches cloned images, using a global master‑slave deployment and LRU eviction for cold images.

Metaserver: metadata manager that records snapshot/clone relationships and routing information, synchronizing with all Chunk services.

Chunk: backend storage engine handling actual read/write of data blocks.

Client: host‑side module that issues VM I/O to the storage cluster.

Ymer: component that copies images from the external image system to the UDisk cluster.

Image Cluster: a special UDisk cluster acting as a cache for base images and cloned system disks.

The system‑disk clone workflow proceeds entirely within the internal cluster when the image already exists, completing in milliseconds without any data copy from the external image system.

Snapshot/Clone Implementation Principles

Key concepts include:

extern_id: globally unique cloud‑disk identifier.

lc (logical disk) and lc_id: logical disk and its internal identifier.

PC (Physical Chunk): 4 MB storage unit managed by Chunk services.

Frigga operates in a master‑slave mode, importing images, managing cache eviction, and limiting the number of clone disks per image to avoid hotspot issues.

Metaserver maintains a chain‑like mapping of logical disks, enabling fast internal cloning by linking clone disks directly to the source image disk; only one copy of the image data is stored, and subsequent clones are memory‑only operations.

Client obtains the mapping from Metaserver to route I/O to the correct Chunk service, ensuring that clone disks read from the same Chunk as their source image, reducing network latency.

Chunk handles I/O at the PC level. Each PC has a bitmap indicating whether a 256 KB segment must be redirected to a parent PC. Read I/O checks the bitmap to decide whether to read locally or follow the parent chain; write I/O redirects data to a new PC when necessary, merging with parent data as required.

Summary

By employing ROW‑based snapshot cloning and an image cache pool, the solution achieves second‑level clone times, allowing the creation of over 1,000 VMs within five minutes and supporting peaks of 2,500 VMs in a single batch. The architecture is already deployed in overseas data centers (Los Angeles, Singapore) and selectively in mainland China, targeting customers with massive, short‑term VM provisioning needs.