Bug 1402581
| Summary: | 'virsh snapshot-create' should have way to default to external snapshots | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Eric Blake <eblake> | |
| Component: | libvirt | Assignee: | Peter Krempa <pkrempa> | |
| Status: | CLOSED WONTFIX | QA Contact: | yisun | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 7.0 | CC: | darkbasic, drjones, dyuan, fedoraproject, jsuchane, jwatt, kchamart, lersek, libvirt-maint, lmen, mike, pkrempa, qizhu, shipatil, xuzhang | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1403951 1519002 (view as bug list) | Environment: | ||
| Last Closed: | 2019-04-24 12:29:11 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1214187, 1342543, 1403951, 1431852, 1519002, 1519003 | |||
|
Description
Eric Blake
2016-12-07 21:33:59 UTC
External snapshots are not on par feature-wise on libvirt thus we can't switch the default yet. 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. 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... 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) This bug is going to be addressed in next major release within existing cloned bug. Jaroslav, can you clarify comment 10? Neither of the marked clones of this bug seem to be the one you referred to. Which bug needs to be followed to track progress on this? (In reply to Jonathan Watt from comment #11) > Jaroslav, can you clarify comment 10? Neither of the marked clones of this > bug seem to be the one you referred to. Which bug needs to be followed to > track progress on this? It should be bug 1519002 . Thanks for the reply. I assumed given that bug 1519002 is locked it must be a security bug rather than a feature bug. It's a bit unfortunate that it being locked prevents many folks from tracking its progress, but I guess there are reasons. (In reply to Jonathan Watt from comment #13) > Thanks for the reply. I assumed given that bug 1519002 is locked it must be > a security bug rather than a feature bug. It's a bit unfortunate that it > being locked prevents many folks from tracking its progress, but I guess > there are reasons. Ah, my apologies, I didn't realized that the bug 1519002 is not public. Anyway, I made it public so you should be able to see it. Thanks. Awesome, thank you! |