[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [RFC Doc V11 3/5] domain snapshot xl design



XL Design

1. User Interface

xl snapshot-create:
  Create a snapshot (disk and RAM) of a domain.

  SYNOPSIS:
    snapshot-create [--live] [--internal|--external] [--path=path] <Domain>
                    [<ConfigFile>]
  OPTIONS:
    -l,--live        take a live snapshot
    -i,--internal    take internal disk snapshots to all disks
    -e,--external    take external disk snapshots to all disks
    -p,--path        path to store snapshot data

    If no options specified and no @ConfigFile specified:
    e.g. # xl snapshot-create domain
    By default, it will create a domain snapshot with default name
    generated according to creation time. This name will be used to
    generate default RAM snaphsot name and disk snapshot name, and
    generate the default directory to store all the snapshot data
    (RAM snapshot file, external disk snapshot files, etc.)
    e.g. result of above command would be:
    default snapshot root directory:
        /var/lib/xen/snapshots/
    default snapshot name generated :
        20150122xxx
    default subdirectory to save data of this snapshot:
        /var/lib/xen/snapshots/domain_uuid/20150122xxx/
    RAM snapshot file:
        By default, it will save memory. Location is here:
        /var/lib/xen/snapshots/domain_uuid/20150122xxx/20150122xxx.save
    disk snapshots:
        By default, to each domain disk, take internal disk snapshot if
        that disk supports, otherwise, take external disk snapshot.

        Internal disk snapshot: take disk snapshot with name 20150122xxx
        External disk snapshot: external file is:
        /var/lib/xen/snapshots/domain_uuid/20150122xxx/vda_20150122xxx.qcow2
        /var/lib/xen/snapshots/domain_uuid/20150122xxx/vdb_20150122xxx.qcow2

    If option includes --live, then the domain is not paused while creating
    the snapshot, like live migration. This increases size of the memory
    dump file, but reducess downtime of the guest.

    If option includes --path, all snapshot data will be saved in this @path.
    If no @ConfigFile:name specified, then use default name (generated by
    time).

    User could specify snapshot information in details through @ConfigFile,
    see following ConfigFile syntax. If configuration in @ConfigFile conflicts
    with options, use options.


xl snapshot-revert:
  Revert domain to status of a snapshot.

  SYNOPSIS:
    snapshot-revert [--pause] [--force] <Domain> <ConfigFile>

  OPTIONS:
    -p,--pause    keep domain paused after the revert
    -f,--force    try harder on risky revert


About domain snapshot delete:
    xl doesn't have snapshot chain information, so it couldn't do the full work.
    If supply:
      xl snapshot-delete <domain> <cfgfile>
    For internal disk snapshot, deleting disk snapshot doesn't need snapshot 
    chain info, this commands can finish the work. But for external disk 
snapshot,
    deleting disk snapshot will need to merge backing file chain, then will need
    the backing file chain information, this command can not finish that.

    So, deleting domain snapshots will be left to user:

    user could delete RAM snapshots and disk snapshots by themselves:
    RAM snapshot file: user could remove it directly.
    Disk snapshots:
      - Internal disk snapshot, issue 'qemu-img snapshot -d'
      - External disk snapshot, basically it is implemented as backing file 
chain.
        Use 'qemu-img commit' to remove one file from the chain and merge its 
data
        forward.        


2. cfgfile syntax

# snapshot name. If user doesn't provide a VM snapshot name, xl will generate
# a name automatically by creation time or by @path basename.
name=""

# save memory or disk-only.
# If memory is '0', doesn't save memory, take disk-only domain snapshot.
# If memory is '1', domain memory is saved.
# Default if 1.
memory=1

# memory location. This field is valid when memory=1.
# If it is set to "", xl will generate a path by creation time or by @path
# basename.
memory_path=""

# disk snapshot specification
#
# Syntax: 'external path, external format, target device'
#
# By default, if no disks is specified here, it will take disk snapshot
# to all disks: take internal disk snapshot if disk support internal disk
# snapshot; and external disk snapshot to other disks.

#disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', ',,hdb',]


3. xl snapshot-xxx implementation

"xl snapshot-create"

    1), parse args or user configuration file.
    2), if saveing memory: save domain (store saved memory to memory_path)
        if taking disk-only snapshot: pause domain, quiece disks. (not
        supported now, maybe in future.)
    3), create disk snapshots according to disk snapshot configuration
    4), unpause domain

"xl snapshot-revert"

    1), parse user configuration file
    2), destroy current domain
    3), revert disk snapshots according to disk snapshot configuration
    4), restore domain from saved memory.

4. Notes

* user should take care of snapshot data: saved memory file, disk
  snapshots info (internal, external, etc.), snapshot chain relationship
* user should delete snapshots by themselves with CLI commands like: rm,
  qemu-img, etc.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.