Bug 1031833

Summary: wrong actual disk size
Product: [Retired] oVirt Reporter: Arik <ahadas>
Component: ovirt-engine-coreAssignee: Tal Nisan <tnisan>
Status: CLOSED CURRENTRELEASE QA Contact: Aharon Canan <acanan>
Severity: high Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: acathrow, ahadas, amureini, iheim, michal.skrivanek, sgotliv, s.kieske, yeylon
Target Milestone: ---   
Target Release: 3.3.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: storage
Fixed In Version: ovirt-3.3.3-beta1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-14 09:56:59 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:
Attachments:
Description Flags
disk with virtual size = 20 gb and actual size = 6200 gb none

Description Arik 2013-11-18 22:27:34 UTC
Created attachment 825831 [details]
disk with virtual size = 20 gb and actual size = 6200 gb

Description of problem:
it seems that there is a bug when we determine the actual disk size that cause it to be huge after running the VM 

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


How reproducible:
always happened to me when I created VMs from the same template of fedora 19

Steps to Reproduce:
1. create template from a VM installed with fedora 19
2. create a VM based on that template
3. run the VM

Actual results:
after the VM starts, the actual size of the disk is huge

Expected results:
the actual size of disk should be less than the virtual size

Additional info:
before running the VM the actual size of my VM's disk was +-3 gb and after running the VM it was changed to +-6200 gb. a screen shot is attached

Comment 1 Allon Mureinik 2013-11-20 14:26:39 UTC
Arik, you did not specify which version this happened on.
Can you provide this info (or better yet, a commit hash)?

Comment 2 Allon Mureinik 2013-11-20 14:27:52 UTC
Arik, you did not specify which version this happened on.
Can you provide this info (or better yet, a commit hash)?

Comment 3 Arik 2013-11-25 13:12:46 UTC
It was +-the latest at the time I opened the bug

Comment 4 Tal Nisan 2013-11-25 16:13:08 UTC
Sergey, if I recall correctly you were working on a related issue, can you please check if it's a dup?

Comment 5 Sandro Bonazzola 2014-02-14 09:56:59 UTC
Closing as 3.3.3 has been released.