This behavior looks like it's controlled by qemu, so I'm changing the component.

Internal snapshots are known to be slow; upstream qemu is working on adding new ways to do snapshots so that internal snapshots are no longer a bottleneck.  However, if you want fast snapshots, I _highly_ recommend using external snapshots instead of internal, as those are lightning fast in comparison, and you don't have to wait for a new qemu.

Thank you for the quick answers.

> However, if you want fast snapshots, I _highly_ recommend using external 
> snapshots instead of internal, as those are lightning fast in comparison
I thought that external snapshots cannot be used as --disk-only only. I need to keep the whole memory state.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> I thought that external snapshots cannot be used as --disk-only only. I need
> to keep the whole memory state.

Saving memory state has been possible in external snapshots since libvirt 1.0.1.

Yes, I recently did a small test. Where even the memory state is also captured with external snapshots. Here is the info:

External system checkpoint snapshot: Guest's disk-state will be saved in
one file, its RAM & device-state will be saved in another file.

Version Info
============

  $ uname -r ; rpm -q qemu-kvm libvirt libguestfs
  3.9.4-301.fc19.x86_64
  qemu-kvm-1.5.0-4.fc19.x86_64
  libvirt-1.0.5.1-1.fc19.x86_64
  libguestfs-1.21.38-1.fc19.x86_64


Snapshot creation
=================

1/ Start the guest:

  $ virsh start fed18
  Domain fed18 started


2/ List its block device in use:

  $ virsh domblklist fed18
  Target     Source
  ------------------------------------------------
  vda        /var/lib/libvirt/images/fed18.qcow2
 
3/ Make an XML file for snapshot:

  $ cat /var/tmp/ext-disk-ram-snap.xml 
  <domainsnapshot>
    <memory snapshot='external' file='/var/lib/libvirt/images/fed18.mem.snap2'/>
    <disks>
      <disk name='vda'>
        <source file='/var/lib/libvirt/images/fed18.disk.snap2'/>
      </disk>
    </disks>
  </domainsnapshot>

4/ Create snapshot (disk & memory state) w/ the the above XML file of the
   running guest:

  $ virsh snapshot-create fed18  \
    --xmlfile /var/tmp/ext-disk-ram-snap.xml --atomic
  Domain snapshot 1370930820 created from '/var/tmp/ext-disk-ram-snap.xml'


5/ List the snapshots:

  $ virsh snapshot-list fed18
   Name                 Creation Time             State
  ------------------------------------------------------------
   1370930820           2013-06-11 11:37:00 +0530 running


6/ Again, list the block device in use (note - the disk image file in use is the
   new qcow2 file we specified in the snapshot XML above):

  $ virsh domblklist fed18
  Target     Source
  ------------------------------------------------
  vda        /var/lib/libvirt/images/fed18.disk.snap2


7/ Find more information about the disk image (it can be seen, qcow2 overlays are
   being used):

  $ qemu-img info --backing-chain /var/lib/libvirt/images/fed18.disk.snap2
  image: /var/lib/libvirt/images/fed18.disk.snap2
  file format: qcow2
  virtual size: 20G (21474836480 bytes)
  disk size: 196K
  cluster_size: 65536
  backing file: /var/lib/libvirt/images/fed18.qcow2
  backing file format: qcow2
  
  image: /var/lib/libvirt/images/fed18.qcow2
  file format: qcow2
  virtual size: 20G (21474836480 bytes)
  disk size: 1.0G
  cluster_size: 65536
  Snapshot list:
  ID        TAG                 VM SIZE                DATE       VM CLOCK
  1         1370847718                0 2013-06-10 12:31:58   00:00:00.000


8/ List both files which has the snapshotted data:

  $ file /var/lib/libvirt/images/fed18.mem.snap2 \
    /var/lib/libvirt/images/fed18.disk.snap2 
  /var/lib/libvirt/images/fed18.mem.snap2:  data
  /var/lib/libvirt/images/fed18.disk.snap2: QEMU QCOW Image (v2), has backing file (path /var/lib/libvirt/images/fed18.qcow2), 21474836480 bytes

Eric, Kashyap, thanks. Indeed, external snapshotting is super fast, and restoring is fast too.

But I have a problem when I try to make a subsequent snapshots: when I make a second snapshot,
everything seems to work, but snapshot-revert restores the *first* snapshot, completely ignoring the second one, to which it was told to revert.

I created a new ext-disk-ram-snap.xml with modified paths:
<domainsnapshot>
  <memory snapshot='external' file='/var/lib/libvirt/images/fedoratestday64.mem.snap4'/>
  <disks>
    <disk name='vda'>
      <source file='/var/lib/libvirt/images/fedoratestday64.disk.snap4'/>
    </disk>
  </disks>
</domainsnapshot>

and created the snapshot

virsh$ snapshot-create fedoratestday64 --xmlfile /var/tmp/ext-disk-ram-snap.xml --atomic

and restored the vm to it:

virsh$ snapshot-revert fedoratestday <snapshot2>

and it returns me to <snapshot1>.

Looking at the xml of snapshot2:
<domainsnapshot>
  <name>1374774685</name>
  <state>running</state>
  <parent>
    <name>1374774274</name>
  </parent>
  <creationTime>1374774685</creationTime>
  <memory snapshot='external' file='/var/lib/libvirt/images/fedoratestday64.mem.snap4'/>
  <disks>
    <disk name='vda' snapshot='external'>
      <driver type='qcow2'/>
      <source file='/var/lib/libvirt/images/fedoratestday64.disk.snap4'/>
    </disk>
    <disk name='hdc' snapshot='no'/>
  </disks>
  <domain type='kvm'>
    <name>fedoratestday64</name>
    <uuid>f1441071-9f40-68fc-13da-3f8355cbfc7b</uuid>
    <memory unit='KiB'>2097152</memory>
    <currentMemory unit='KiB'>2097152</currentMemory>
    <vcpu placement='static'>2</vcpu>
    <resource>
      <partition>/machine</partition>
    </resource>
    <os>
      <type arch='x86_64' machine='pc-i440fx-1.4'>hvm</type>
      <boot dev='hd'/>
    </os>
    <features>
      <acpi/>
      <apic/>
      <pae/>
    </features>
    <clock offset='utc'/>
    <on_poweroff>destroy</on_poweroff>
    <on_reboot>restart</on_reboot>
    <on_crash>restart</on_crash>
    <devices>
      <emulator>/usr/bin/qemu-kvm</emulator>
      <disk type='file' device='disk'>
        <driver name='qemu' type='qcow2'/>
        <source file='/var/lib/libvirt/images/fedoratestday64.disk.snap2'/>
        <target dev='vda' bus='virtio'/>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
      </disk>
      <disk type='file' device='cdrom'>
        <driver name='qemu' type='raw'/>
        <source file='/home/zbyszek/images/testday-20130530-x86_64.iso'/>
        <target dev='hdc' bus='ide'/>
        <readonly/>
        <address type='drive' controller='0' bus='1' target='0' unit='0'/>
      </disk>
      <controller type='ide' index='0'>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
      </controller>
      <controller type='virtio-serial' index='0'>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
      </controller>
      <controller type='usb' index='0'/>
      <controller type='pci' index='0' model='pci-root'/>
      <interface type='network'>
        <mac address='52:54:00:85:40:50'/>
        <source network='default'/>
        <model type='virtio'/>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
      </interface>
      <serial type='pty'>
        <target port='0'/>
      </serial>
      <console type='pty'>
        <target type='serial' port='0'/>
      </console>
      <channel type='spicevmc'>
        <target type='virtio' name='com.redhat.spice.0'/>
        <address type='virtio-serial' controller='0' bus='0' port='1'/>
      </channel>
      <input type='tablet' bus='usb'/>
      <input type='mouse' bus='ps2'/>
      <graphics type='spice' autoport='yes' listen='127.0.0.1'>
        <listen type='address' address='127.0.0.1'/>
      </graphics>
      <sound model='ich6'>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
      </sound>
      <video>
        <model type='qxl' ram='65536' vram='65536' heads='1'/>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
      </video>
      <memballoon model='virtio'>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
      </memballoon>
    </devices>
    <seclabel type='dynamic' model='selinux' relabel='yes'/>
  </domain>
</domainsnapshot>

Both /var/lib/libvirt/images/fedoratestday64.disk.snap2 and /var/lib/libvirt/images/fedoratestday64.disk.snap4 are there, and .snap4 is in the wrong place?

Reverting to external snapshots is still under development in libvirt (see for example bug 987719); if you are trying to revert to an external snapshot, please ask on the libvirt-users list for steps to take to do the manual pieces that are not yet in place in libvirt proper.

Unfortunately, bug 987719 isn't public, but the gist of the bug summary is "support deletion of external snapshots".  Eric, is there anywhere on the libvirt.org wiki with the manual steps?

Should this be moved to the libvirt upstream product then?

(In reply to Paolo Bonzini from comment #9)
> Should this be moved to the libvirt upstream product then?

Libvirt already has bugs tracking the need to implement snapshot-delete/revert for external snapshots, which is a secondary issue.  This bug's primary issue is still about the slowness of qemu's internal snapshots, some of which may be addressed by pending upstream work for qemu 1.6 (or maybe 1.7, as we have already entered soft freeze for 1.6).  I've retitled the bug accordingly.

(In reply to Dave Allan from comment #8)
> Unfortunately, bug 987719 isn't public, but the gist of the bug summary is
> "support deletion of external snapshots".  Eric, is there anywhere on the
> libvirt.org wiki with the manual steps?

I'll double check that (which probably means adding such a page), and post a URL back when I'm happy with the result.

I've started a wiki page; I still need to work on it more, but as it is a wiki, hopefully it will be something we can make more useful.

http://wiki.libvirt.org/page/I_created_an_external_snapshot%2C_but_libvirt_won%27t_let_me_delete_or_revert_to_it

To avoid any scary backports let's just track this against F20, that's where we have the virt-manager support as well.

F20/qemu 1.6 is much better here, but there's apparently an issue with slowness after the first internal snapshot. Patch here: https://lists.gnu.org/archive/html/qemu-devel/2013-09/msg02353.html

qemu-1.6.0-9.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/qemu-1.6.0-9.fc20

Package qemu-1.6.0-9.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing qemu-1.6.0-9.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-18471/qemu-1.6.0-9.fc20
then log in and leave karma (feedback).

qemu-1.6.0-10.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/qemu-1.6.0-10.fc20

qemu-1.6.0-10.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.