Bug 1091328
| Summary: | RFE: VM snapshots as series qcow backing store images | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Samo Dadela <samo_dadela> |
| Component: | virt-manager | Assignee: | Cole Robinson <crobinso> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | berrange, crobinso, virt-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-04-25 12:45:09 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: | |||
Libvirt has some machinery for this already, but it needs much more API support for virt-manager to provide the behavior you describe. Duping to one of the upstream libvirt bugs tracking a piece of this. *** This bug has been marked as a duplicate of bug 1044691 *** |
Description of problem: Would it be possible to take VM snapshots and store them as a chain of separate qcow2 files. Each new snapshot uses as the backing store the previous one. img1 (rh6.5 install) <-> img2 (install Oracle) | |-> img3 (install web server) This way a lot of disk space would be saved. All RH systems would reference just the img1. All web servers would reference img3. Of course we would need to keep track which vm uses which backing store to avoid modifying it or deleting it. I know it is currently possible to specify a backing store, but that must all be done manually and I don't know what happens if you specify a qcow img that has multiple snapshots. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: