Bug 1402581 - 'virsh snapshot-create' should have way to default to external snapshots
Summary: 'virsh snapshot-create' should have way to default to external snapshots
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Peter Krempa
QA Contact: yisun
Depends On:
Blocks: 1519002 1519003 1214187 1342543 1403951 1431852
TreeView+ depends on / blocked
Reported: 2016-12-07 21:33 UTC by Eric Blake
Modified: 2019-04-24 12:29 UTC (History)
13 users (show)

Clone Of:
: 1403951 1519002 (view as bug list)
Last Closed: 2019-04-24 12:29:11 UTC

Attachments (Terms of Use)

Description Eric Blake 2016-12-07 21:33:59 UTC
Description of problem:
For historical reasons, 'virsh snapshot-create' defaults to internal snapshots, because external snapshots were not implemented for several years.  However, these days the qemu team recommends the use of external snapshots, and upper levels like RHEV prefer external snapshots.  It would be nice if there were a way to set up configuration defaults for virsh, so that typing 'virsh snapshot-create' could consult the configuration file on whether to default to internal or external, instead of forcing the user to remember to pass extra flags to get an external snapshot.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

Comment 5 Peter Krempa 2017-01-17 08:59:12 UTC
External snapshots are not on par feature-wise on libvirt thus we can't switch the default yet.

Comment 6 Laszlo Ersek 2017-02-24 23:50:15 UTC
When designing this feature for virsh (and virt-manager), please don't forget about the UEFI varstore files (under /var/lib/libvirt/qemu/nvram), which are technically raw drives, but have very different storage properties from normal drives. They don't live in storage pools, they are not on shared storage, and also not subject to storage migration. QEMU automatically writes them out fully on the target host after migration finishes.

I'm unsure how this interacts with external snapshots, but I figure I'd better raise it. Thanks.

Comment 7 Niccolò Belli 2018-09-24 19:16:11 UTC
Is there currently any way to take a snapshot of a running VM (and restore it) *including* its ram state?
If you don't save the ram state it's basically like pulling the power cord...

Comment 8 Peter Krempa 2018-09-25 08:44:48 UTC
Taking the ram state is possible when you use the --memspec argument of virsh snapshot-create-as (or create the XML with the corresponding element for the memory snapshot target).

Restoring of external snapshots is possible only manually depending on what you want to achieve. (plain revert without creating a second set of overlay disks will invalidate the most recent state). For restoring a snapshot with memory the 'virsh restore' command can be used with the memory state image, but special care needs to be used with the configuration if you care about the most recent state. (new updated XML needs to be passed via the --xml attribute and overlay disk images need to be created)

Comment 10 Jaroslav Suchanek 2019-04-24 12:29:11 UTC
This bug is going to be addressed in next major release within existing cloned bug.

Note You need to log in before you can comment on or make changes to this bug.