unable to create snapshot

Bug #1417288 reported by ben thielsen on 2015-02-02
This bug affects 3 people
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Stefan Bader

Bug Description

the following occurs when attempting to create a snapshot:

virsh # snapshot-create-as template-generic 'test_snapshot' 'test snapshot' --disk-only --atomic
error: unsupported configuration: cannot generate external snapshot name for disk 'vda' without source

virsh # snapshot-create-as template-generic 'test_snapshot' 'test snapshot' --atomic
error: internal error: Child process (/usr/bin/qemu-img snapshot -c test_snapshot) unexpected exit status 1: qemu-img: Expecting one image file name
Try 'qemu-img --help' for more information

the guest is not running:
virsh # list --all
 Id Name State
 - template-generic shut off

here is the guest xml:

virsh # dumpxml template-generic
<domain type='kvm'>
  <description>generic template</description>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>1</vcpu>
    <type arch='x86_64' machine='pc-q35-2.1'>hvm</type>
    <boot dev='hd'/>
  <cpu mode='host-passthrough'>
  <clock offset='utc'/>
    <disk type='volume' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source pool='disks-local' volume='template-generic.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x7'/>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0' multifunction='on'/>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='dmi-to-pci-bridge'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/>
    <controller type='pci' index='2' model='pci-bridge'>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/>
    <interface type='network'>
      <mac address='52:54:00:5c:51:ce'/>
      <source network='virtual-bridge' portgroup='it_net_admins'/>
      <model type='virtio'/>
      <driver name='vhost' txmode='iothread'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/>
    <input type='keyboard' bus='usb'/>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes' listen=''>
      <listen type='address' address=''/>
      <model type='qxl' ram='65536' vram='65536' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/>

1] >lsb_release -rd
Description: Ubuntu 14.10
Release: 14.10

2] >apt-cache policy libvirt-bin
  Installed: 1.2.8-0ubuntu11.2
  Candidate: 1.2.8-0ubuntu11.2
  Version table:
 *** 1.2.8-0ubuntu11.2 0
        500 http://us.archive.ubuntu.com/ubuntu/ utopic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.2.8-0ubuntu11.1 0
        500 http://security.ubuntu.com/ubuntu/ utopic-security/main amd64 Packages
     1.2.8-0ubuntu11 0
        500 http://us.archive.ubuntu.com/ubuntu/ utopic/main amd64 Packages

3] i expected a snapshot to be created

4] the above errors

Serge Hallyn (serge-hallyn) wrote :

Hm, I can't reproduce this:

virsh !!
virsh snapshot-create-as debianwheezy 'test_snapshot' 'test snapshot' --atomic
Domain snapshot test_snapshot created

Serge Hallyn (serge-hallyn) wrote :

Just to be sure, could you confirm that 1.2.8-0ubuntu11.4 still has this behavior?

ben thielsen (btb-bitrate) wrote :

yes, it still has this behavior with 1.2.8-0ubuntu11.4

Changed in libvirt (Ubuntu):
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libvirt (Ubuntu):
status: New → Confirmed
Stefan Bader (smb) wrote :

I was able to to reproduce this. The important detail is to use the disk type "volume" not "file" as we normally do.

Changed in libvirt (Ubuntu):
assignee: nobody → Stefan Bader (smb)
Stefan Bader (smb) wrote :

I looked a bit more into this and more and more get the impression that this particular setup has not and is not supported.

Ben, did snapshots with type volume storage definitions ever work for you? And the other question would be whether it is possible to convert the currents guests and the process of creating new guests to use the type=file format of storage definitions.

A bit more background: snapshots are only supported on file-backed disks. When defining a disk as type=volume, the internal structure that holds the disk stores both the volume name (type=volume) and the path (type=file) in the same source element. But all the code for snapshots assumes a local path in there. For type=volume this would require additional checking (since there are pools that do not contains file backed volumes) and re-direction (to resolve the volume name into a path). None of this is present even in the recent releases of libvirt. So it might be a restriction that has not been documented well.

Stefan Bader (smb) on 2015-08-27
Changed in libvirt (Ubuntu):
status: Confirmed → Incomplete
ben thielsen (btb-bitrate) wrote :

thanks for the time you've devoted to this. your assessment seems to be exactly the case, given a little more testing here. i've converted to a disk type of file, and snapshots work [mostly - see my next comment].

i'd never used/tried snapshots with this particular configuration. i'm sure you're right - it probably didn't ever work. although i really do like being able to use pools and volumes, for the sake of structure and organization and being able to avoid literal filesystem paths within guest definitions, i've switched from volumes back to files, since i don' really have a choice if i want snapshots.

from a practical standpoint, it would be nice to have this functionality.

ben thielsen (btb-bitrate) wrote :

i can now create snapshots if using --disk-only, but i guess this is an "external" snapshot? which leads to other problems, like not being able to delete it:

>virsh snapshot-create-as orb-template-ubuntu 'test_snapshot_3' 'test snapshot 3'
error: operation failed: Error -22 while writing VM

>virsh snapshot-create-as orb-template-ubuntu 'test_snapshot_3' 'test snapshot 3' --atomic
error: operation failed: Error -22 while writing VM

>virsh snapshot-create-as orb-template-ubuntu 'test_snapshot_3' 'test snapshot 3' --atomic --disk-only
Domain snapshot test_snapshot_3 created

>virsh snapshot-list orb-template-ubuntu
 Name Creation Time State
 test_snapshot 2015-09-23 15:07:02 -0400 disk-snapshot
 test_snapshot_2 2015-09-23 15:07:44 -0400 disk-snapshot
 test_snapshot_3 2015-09-23 15:55:18 -0400 disk-snapshot

>virsh snapshot-delete orb-template-ubuntu test_snapshot_3
error: Failed to delete snapshot test_snapshot_3
error: unsupported configuration: deletion of 1 external disk snapshots not supported yet

Stefan Bader (smb) wrote :

I noticed this, too. And that it seemed to work with later releases. However this is only half true. Actually that error still exists in the tip of the libvirt tree. There is only on commit that fixed an inconsistency related to the --children option with a note saying it would be nice if we would support deletion of external snapshots one day.

So deletion in Trusty/14.04 (still?) requires to add "--metadata" (only deletes the info but leaves the snapshot file which then has to be removed manually outside libvirt).

Stefan Bader (smb) wrote :

Lowering the priority here. Not really sure this will be ever fixed. But likely need to revisit the latest libvirt.

Changed in libvirt (Ubuntu):
importance: High → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers