Bug 1015651

Summary:	[RFE] reduce the disk space inflated by snapshots
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Robert McSwain <rmcswain>
Component:	RFEs	Assignee:	Allon Mureinik <amureini>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Aharon Canan <acanan>
Severity:	high	Docs Contact:
Priority:	high
Version:	3.2.0	CC:	amureini, byount, fgarciad, fsimonce, iheim, lpeer, mkalinin, pablo.iranzo, rbalakri, Rhev-m-bugs, riehecky, rmcswain, rpai, scohen, sigbjorn, sputhenp, yeylon, ylavi
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	sherold: Triaged+
Hardware:	Unspecified
OS:	Linux
Whiteboard:	storage
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-01-27 11:58:19 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:	977778
Bug Blocks:

Description Robert McSwain 2013-10-04 17:44:50 UTC

Description of problem:
Snapshot with the description "Auto-generated for Live Storage Migration" has ballooned to 2.5 TB, causing the VM to not be able to be started

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

How reproducible:
Unknown at this time. The snapshot is Pre Allocated rather than Thin Provisioned. This provides the assumption that this should've been thin-provisioned instead? 

Steps to Reproduce:
1. Unknown at this time

Actual results:
The snapshot for generated via LSM has grown large enough that the VM is unable to start and the entire storage domain is full.

Expected results:
The snapshot does not take up the entire storage domain and hinder the ability of the VM to run

Additional info:

Comment 4 Federico Simoncelli 2013-10-06 15:45:07 UTC

We still have to little information to understand what happened but the first thing that comes to my mind is that this could this be a duplicate of bug 998443.

Comment 9 Ayal Baron 2013-10-16 10:30:02 UTC

What you're actually asking for here is to shrink the size of the backing file.
To do this we'd need to be able to introspect on the content of the disk (since it is raw and we have no idea what blocks are already in use), move blocks around internally so that they're sequential on disk and then shrink the LV to the actual size used.

This may be possible to do offline with something like libguestfs

Comment 10 Allon Mureinik 2013-10-20 10:11:56 UTC

Reducing severity as per comment 9

Comment 17 Marina Kalinin 2018-08-15 22:15:14 UTC

Changing title, since the current title has nothing to do with bug description or bug resolution.