unable to create snapshot

Bug #1417288 reported by ben thielsen
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Fix Released
Low
Unassigned
Bionic
Won't Fix
Low
Unassigned
Focal
Won't Fix
Low
Unassigned
Groovy
Won't Fix
Low
Unassigned
Hirsute
Fix Released
Undecided
Unassigned

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'>
  <name>template-generic</name>
  <uuid>c2fcf78b-5919-45f6-af1f-cc540fa5f218</uuid>
  <description>generic template</description>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-2.1'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode='host-passthrough'>
  </cpu>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <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'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x7'/>
    </controller>
    <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>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <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>
    <controller type='pci' index='2' model='pci-bridge'>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/>
    </controller>
    <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'/>
    </interface>
    <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='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
    <video>
      <model type='qxl' ram='65536' vram='65536' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/>
    </memballoon>
  </devices>
</domain>

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

2] >apt-cache policy libvirt-bin
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

Revision history for this message
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

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

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

Revision history for this message
ben thielsen (btb-bitrate) wrote :

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

Changed in libvirt (Ubuntu):
importance: Undecided → High
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in libvirt (Ubuntu):
status: New → Confirmed
Revision history for this message
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)
Revision history for this message
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)
Changed in libvirt (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
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.

Revision history for this message
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

Revision history for this message
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).

Revision history for this message
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
Revision history for this message
Garry Lawrence (invalidinterrupt) wrote :

This appears to have already been fixed for some cases. I was able to snapshot a qcow2 volume on 21.04 (libvirt 7.0.0).

Upstream discussion (I think this is the relevant change): https://gitlab.com/libvirt/libvirt/-/issues/97

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

There still are known issues around volume usage with apparmor isolation which are tracked elsewhere. But you are right - thanks Garry - one of the inderlying issues about
a) modifying non-local storage (https://listman.redhat.com/archives/libvir-list/2020-November/msg01252.html)
b) internatl snapshots translation on type=vollume (https://listman.redhat.com/archives/libvir-list/2020-November/msg01253.html)
Are fixed by this series (the rest improves the abort and error messages).

That series is in libvirt since v6.10 .0 and thereby it is indeed in 21.04 and later.

Changed in libvirt (Ubuntu Hirsute):
status: New → Fix Released
Changed in libvirt (Ubuntu Groovy):
status: New → Incomplete
Changed in libvirt (Ubuntu Focal):
status: New → Incomplete
Changed in libvirt (Ubuntu Bionic):
status: New → Incomplete
importance: Undecided → Low
Changed in libvirt (Ubuntu Focal):
importance: Undecided → Low
Changed in libvirt (Ubuntu Groovy):
importance: Undecided → Low
Changed in libvirt (Ubuntu):
assignee: Stefan Bader (smb) → nobody
status: Incomplete → Fix Released
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Following the arguments made before on this bug about this being an uncommon or maybe even unsupported setup variant I'm marking the tasks that represent backports as won't fix.

This setup only becomes more reasonable after [1] which isn't on anyone's active work-queue atm AFAIK - and even then is a new feature unlikely to be backported.

[1]: https://gitlab.com/libvirt/libvirt/-/issues/135

Changed in libvirt (Ubuntu Bionic):
status: Incomplete → Won't Fix
Changed in libvirt (Ubuntu Focal):
status: Incomplete → Won't Fix
Changed in libvirt (Ubuntu Groovy):
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.