with VirtualBox it’s the same. THEORETICALLY they support Micro$oft’$ HYPER_V_DISK_IMAGE.VHD BUT PRACTICALLY THINGS WILL FALL APART QUICKLY! (broken/corrupted disk image)

So just stick to the defaults and you should be good. (in case of VirtualBox it’s VIRTUALBOX_VM_HARDDISK.VDI format in case of KVM it’s KVM_VM_HARDDISK.qcow2)

looking for virt-manager snapshot feature?

you have come to the right place. it’s not where you expect it to be: (not in a menu of the main gui or in a r-click sub-menu)

virt-manager gui screenshot - no snapshots

1. select a vm & click open

2. klick on manage VM snapshots

virt-manager take snapshot of vm

3. here we go … 😉

virt-manager take snapshot of vm3 virt-manager take snapshot of vm2


Two Types of snapshots

Internal snapshots (that’s what virt-manager does – all in one file)

Internal snapshots are the snapshots that QEMU has supported for a long time. Libvirt refers to them as ‚internal‘ because all the data is stored as part of the qcow2 disk image: if you have a VM with a single qcow2 disk image and take 10 snapshots, you still have only one file to manage. This is the default snapshot mode if using the ‚virsh snapshot-*‘ commands.

These snapshots can be combine disk and VM memory state for ‚checkpointing‘, so you can jump back and forth between a saved running VM state. A snapshot of an offline VM can also be performed, and only the disk contents will be saved.


  • Only works with qcow2 disk images. Since virt-manager has historically used raw images, pre-existing VMs may not be able to work with this type.
  • They are non-live, meaning the VM is paused while all the state is saved. For end users this likely isn’t a problem, but if you are managing a public server, minimizing downtime is essential.
  • Historically they were quite slow, but this has improved quite a bit with QEMU 1.6+


External snapshots

External snapshots are about safely creating copy-on-write overlay files for a running VM’s disk images. QEMU has supported copy-on-write overlay files for a long time, but the ability to create them for a running VM is only a couple years old. They are called ‚external‘ because every snapshot creates a new overlay file.

While the overlay files have to be qcow2, these snapshots will work with any base disk image. They can also be performed with very little VM downtime, at least under a second. The external nature also allows different use cases like live backup: create a snapshot, back up the original backing image, when backup completes, merge the overlay file changes back into the backing image.

However that’s mostly where the benefits end. Compared to internal snapshots, which are an end to end solution with all the complexity handled in QEMU, external snapshots are just a building block for handling the use cases I described above… and the many of the pieces haven’t been filled in yet. Libvirt still needs a lot of work to reach feature parity with what internal snapshots already provide. This is understandable, as the main driver for external snapshot support was for features like live backup that internal snapshots weren’t suited for. Once that point was reached, there hasn’t been much of a good reason to do the difficult work of filling in the remaining support when internal snapshots already fit the bill.

virt-manager support

Understandably we decided to go with internal snapshots in virt-manager’s UI. To facilitate this, we’ve changed the default disk image for new qemu/kvm VMs to qcow2.

Source & Creditz:

btw if you get:

Error starting domain: internal error Network 'default' is not active.

So here is how to fix that:

sudo virsh net-start default
sudo virsh net-autostart default

gui-way Android

the only gui that can do snapshots seems to be … and it’s an ANDROID APP? 😀 WTF.

How do i install Android Apps on a Linux Debian machine? (you do not… unless you run it inside some emulator… which is a little cumbersome isn’t it?)


Snapshots in QEMU are images that refer to an original image using Redirect-on-Write [1] to avoid changing the original image. If you want to create a snapshot of an existing image called centos-cleaninstall.img, create a new QCow2 file using the -b flag to indicate a backing file. The new image is now a read/write snapshot of the original image — any changes to snapshot.img will not be reflected in centos-cleaninstall.img.

qemu-img create -f qcow2 -b centos-cleaninstall.img snapshot.img




Please subscribe to their Mailinglist:

and give the creators a „thanks buddy“ shout.