3:23 p.m.
On 02/01/2013 11:12 AM, Andrew Martin wrote:
> Are you using the --disk-only and/or --memspec options when you
use
> snapshot-create-as? Or put another way, are your snapshots internal
> or external?
Here's the full command I've been using:
virsh snapshot-create-as --domain "$VM_NAME" --name "$SNAP_NAME"
--disk-only --atomic
That's external.
Can you elaborate on the difference between internal and external
snapshots? The snapshots I created with the above command are contained
in separate qcow2 backing files, which I would think to be external, but
snapshot-info shows them as internal?
Any snapshot created without --disk-only and without --memspec is
internal - it resides completely within an existing qcow2 image (no new
files are created). All snapshots with --disk-only or --memspec are
external; the domain state is now spread across multiple files.
If snapshot-info shows a --disk-only snapshot as internal, then that's a
bug, and we need to fix it. What version of libvirt did you test?
>From what I can see there are 3 different types of snapshots:
1. internal (offline) qcow2 snapshots created with qemu-img snapshot
2. external (live) snapshots with --disk-only
3. external (live) snapshots with --memspec and/or --diskspec
Or, am I misunderstanding what --disk-only and --diskspec do?
There's actually:
1. internal offline: internal qcow2 snapshots (disk-only) created with
'snapshot-create-as' with no flags for offline guest [wired to 'qemu-img
snapshot' under the hood]
2. internal online: internal qcow2 snapshots (disk and memory) created
with 'snapshot-create-as' with no flags for online guest [wired to qemu
'savevm' HMP command]
3. external offline: qcow2 wrapper around any base file type, created
with 'snapshot-create-as --disk-only' for offline guest [wired to
'qemu-img create']
4. external online disk-only: qcow2 wrapper around any base file type,
created with 'snapshot-create-as --disk-only' for online guest [wired to
qemu 'transaction' QMP command]
5. external online memory: qcow2 wrapper around any base file type plus
migration to file, created with 'snapshot-create-as --memspec' for
online guest [wired to qemu 'migrate' and 'transaction' QMP commands]
6. external memory only: migration to file, created with 'virsh save'
for online guest [wired to qemu 'migrate' QMP command]
There's also talk on the upstream qemu list about making even more
options for snapshots (for example, 'savevm' is too bulky for creating
internal qcow2 snapshots, so the goal is to allow for an internal qcow2
snapshot without also grabbing guest memory; also, live migration to
file is a waste of disk space on a guest that takes a long time to
converge, so a new file format for storing guest memory would make live
snapshots take less disk space).
> For internal snapshots, it should just work; when reverting, it
> shouldn't matter whether the domain is live or shutdown, because
> you are going to change state anyway. Internal snapshots are not
> invalidated (the way qcow2 works, each internal snapshot increments a
> reference counter on all clusters in use at the time of the snapshot,
> with no intrinsic relation between snapshots; executing from the point
> of a given snapshot does a copy-on-write allocation for any cluster
> with a reference count larger than 1).
Since they are separate copy-on-write snapshots, this means I could
revert to snap1, make changes, and then later revert to snap3?
For internal snapshots, yes. For external snapshots, the act of
reverting is not yet wired up nicely in libvirt 1.0.2; basically, doing
a revert of an external snapshot needs to decide whether to create
another snapshot (by adding an atomic revert-and-create action), or to
invalidate all existing snapshots that descend below the point being
reverted to.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org