[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
>>> On 12/17/2014 at 08:17 PM, in message <20141217121750.GF1904@xxxxxxxxxxxxxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx> wrote: > On Tue, Dec 16, 2014 at 02:32:55PM +0800, Chunyan Liu wrote: > > Changes to V8: > > * add an overview document, so that one can has a overall look > > about the whole domain snapshot work, limits, requirements, > > how to do, etc. > > > > ===================================================================== > > Domain snapshot overview > > > > 1. Purpose > > > > Domain snapshot is a system checkpoint of a domain. Later, one can > > roll back the domain to that checkpoint. It's a very useful backup > > function. A domain snapshot contains the memory status at the > > checkpoint and the disk status (which we called disk snapshot). > > > > Domain snapshot functionality usually includes: > > a) create a domain snapshot > > b) roll back (or called "revert") to a domain snapshot > > c) delete a domain snapshot > > d) list all domain snapshots > > > > But following the existing xl idioms of managing storage and saved > > VM images via existing CLI command (qemu-img, lvcreate, ls, mv, > > cp etc), xl snapshot functionality would be kept as simple as > > possible: > > * xl will do a) and b), creating a snapshot and reverting a > > domain to a snapshot. > > * xl will NOT do c) and d), xl won't manage snapshots, as xl > > doesn't maintain saved images created by 'xl save'. So xl > > will have no idea of the existence of domain snapshots and > > the chain relationship between snapshots. It will depends on > > user to take care of the snapshots, know the snapshot chain > > info, and delete snapshots. > > > > Domain Snapshot Support and Not Support: > > I think this list applies to xl (last item and [1]). If so please state > clearly to prevent confusion with other toolstack (say, libvirt) and > functionalities of the library (libxl). > > > * support live snapshot > > * support internal disk snapshot and external disk snapshot > > * support different disk backend types. > > (Basic goal is to support 'raw' and 'qcow2' only). > > > > * not support snapshot when domain is shutdowning or dying. > > * not support disk-only snapshot [1]. > > > > [1] To xl, it only concerns active domains, and even when domain > > is paused, there is no data flush to disk operation. So, take > > a disk-only snapshot and then resume, it is as if the guest > > had crashed. For this reason, disk-only snapshot is meaningless > > to xl. Should not support. > > > > I think I understand your reasoning, but it's a bit convoluted to me. > > Domain can be in both active and inactive state (libvirt term) when > using xl. When domain is active, we cannot guarantee in xl that domain > is quiesced so a disk-only snapshot may contain inconsistent data. That's right. > When > domain is inactive, there's no point in taking a disk-only snapshot > because it would be the same as the base image. xl doesn't have inactive domains. Libvirt has. (in libvirt, one can 'define' a domain but not 'starte', like old xend which can 'new' a domain but not 'start' it.) xl only can 'create' a domain, when domain is shutdown, it's not visible to user. For inactive domain, disk-only snapshot is useful. Since later user may run VM with base image and base image would change. Then the disk-only snapshot is a usable backup. That's why, libvirt can support disk-only snapshot, xl won't support disk-only snapshot. Do I describe it clearly? > So the conclusion is > that xl doesn't need to support disk-only snapshot. > > Does the above reasoning equals to yours? Is it clearer or more > confusing? > > Wei. > > > > > 2. Requirements > > > > General Requirements: > > * ability to save/restore domain memory > > * ability to create/delete/apply disk snapshot [2] > > * ability to parse user config file > > > > [2] Disk snapshot requirements: > > - external tools: qemu-img, lvcreate, vhd-util, etc. > > - for basic goal, we support 'raw' and 'qcow2' backend types > > only. Then it requires: > > libxl qmp command or "qemu-img" (when qemu process does not > > exist) > > > > > > 3. Interaction with other operations: > > > > No. > > > > > > 4. General workflow > > > > Create a snapshot: > > * parse user cfg file if passed in > > * check snapshot operation is allowed or not > > * save domain, saving memory status to file (refer to: save_domain) > > * take disk snapshot (e.g. call qmp command) > > * unpause domain > > > > Revert to snapshot: > > * parse use cfg file (xl doesn't manage snapshots, so it has no > > idea of snapshot existence. User MUST supply configuration file) > > * destroy this domain > > * create a new domain from snapshot info > > - apply disk snapshot (e.g. call qemu-img) > > - a process like restore domain > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |