Proposal: Disk import/export

From Xen
Revision as of 10:58, 24 September 2013 by Dave.scott (talk | contribs) (Proposal to improve disk import/export)

Proposal to improve disk import/export

There are various ways to move a disk into or out of a system via the XenAPI, both "official" (ie. via an API) and "unofficial" (ie. by working around missing APIs). Many of the "official" ways to move disks around use non-standard and poorly-documented protocols and formats, which inhibits interoperability with other services such as CloudStack and OpenStack. The "unofficial" ways are often risky since they potentially conflict with running operations (e.g. vhd coalesce).

Disk import/export is a fundamental ability of a virtualisation platform, and good support for it is demanded by all users: traditional server virt users need off-site incremental backup; cloud orchestration layers need to deploy images from central repositories; everyone benefits from being able to quickly move gold image disk volumes around.

This document starts with an overview of what we currently have; followed by an analysis of use-cases we'd like to support (or improve our support for); followed by a set of principles to govern our designs; and finally by a proposed set of APIs and CLI commands.

What do we currently have?

The following sections describe the current mechanisms, who is known to use them, advantages and disadvantages of each.

HTTP PUT raw disk contents

HTTP PUT with 'chunked' encoding

Network Block Device (NBD) access

VM import/export

HTTP BITS via transfer VM

vhd manipulation through plugins

Desired use-cases

Principles

This section proposes some guiding principles to help guide the shape of the API.

Possibilities include:

  1. use of a nominated standard format for all exported and imported disk data (e.g. vhd now; qcow2 or vhdx later?). Note this doesn't say anything about the runtime format of the disk.
  2. always supporting resumption of interrupted transfers, since vhds are large

API changes