Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 847800

Summary: webadmin: disk actual size is reported incorrectly when adding a snapshot
Product: Red Hat Enterprise Virtualization Manager Reporter: Dafna Ron <dron>
Component: ovirt-engine-webadmin-portalAssignee: Tal Nisan <tnisan>
Status: CLOSED CURRENTRELEASE QA Contact: Dafna Ron <dron>
Severity: medium Docs Contact:
Priority: high    
Version: 3.1.0CC: abaron, amureini, dyasny, ecohen, iheim, Rhev-m-bugs, sgrinber, tnisan, ykaul
Target Milestone: ---Keywords: Regression, Reopened
Target Release: 3.1.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: storage
Fixed In Version: SI20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-04 20:05:34 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:
Embargoed:
Attachments:
Description Flags
logs and screen shots
none
screen shot none

Description Dafna Ron 2012-08-13 15:32:26 UTC
Created attachment 604026 [details]
logs and screen shots

Description of problem:

if I create a preallocated disk+snapshot the disk actual size should be disk size+1GB, so if the disk was created as preallocated 10GB after the snapshot it should be 11GB. 

currently we are reporting the disk as 1GB

after checking on 3.0 with wpf and webadmin on the same system we can see that the actual size in wpf is reported correctly while in wenadmin its reported incorrectly on the same vm. 

I added a screenshot of the vm from the storage view which is reporting the disk size as it should appear in the disks sub tab.

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

si13.2

How reproducible:

100%

Steps to Reproduce:
1. create a vm with preallocated disk of 10GB -> disk size and actual size should both be 10GB
2. create a snapshot 
3.
  
Actual results:

the disk actual size is reported as 1GB 

Expected results:

disk should be reported as 11GB. 

Additional info: logs and screen shot are attached 

LV                                   VG                                   Attr     LSize   Pool Origin Data%  Move Log Copy%  Convert
  ids                                  270af8f1-5bdb-42d7-9e0b-cea74762c1d9 -wi-ao-- 128.00m                                           
  inbox                                270af8f1-5bdb-42d7-9e0b-cea74762c1d9 -wi-a--- 128.00m                                           
  leases                               270af8f1-5bdb-42d7-9e0b-cea74762c1d9 -wi-a---   2.00g                                           
  master                               270af8f1-5bdb-42d7-9e0b-cea74762c1d9 -wi-a---   1.00g                                           
  metadata                             270af8f1-5bdb-42d7-9e0b-cea74762c1d9 -wi-a--- 512.00m                                           
  outbox                               270af8f1-5bdb-42d7-9e0b-cea74762c1d9 -wi-a--- 128.00m                                           
  bd0d7aaf-e0b5-4c95-8377-162f30ae1847 731136fe-8e6d-4838-9486-2495a03b7fb4 -wi-----  10.00g                                           
  d7da1f9e-c89a-44cb-8667-92376222e439 731136fe-8e6d-4838-9486-2495a03b7fb4 -wi-----   1.00g                                           
  ids                                  731136fe-8e6d-4838-9486-2495a03b7fb4 -wi-ao-- 128.00m                                           
  inbox                                731136fe-8e6d-4838-9486-2495a03b7fb4 -wi-a--- 128.00m                                           
  leases                               731136fe-8e6d-4838-9486-2495a03b7fb4 -wi-a---   2.00g                                           
  master                               731136fe-8e6d-4838-9486-2495a03b7fb4 -wi-ao--   1.00g                                           
  metadata                             731136fe-8e6d-4838-9486-2495a03b7fb4 -wi-a--- 512.00m                                           
  outbox                               731136fe-8e6d-4838-9486-2495a03b7fb4 -wi-a--- 128.00m                                           
  lv_home                              vg0                                  -wi-ao-- 101.08g                                           
  lv_root                              vg0                                  -wi-ao--  19.53g                                           
  lv_swap                              vg0                                  -wi-ao--  15.62g                                           
[root@localhost ~]#

Comment 2 Tal Nisan 2012-09-23 10:54:10 UTC
Size is reported correctly according to the actual image size, tested with "ls --size" to make sure

Comment 3 Dafna Ron 2012-09-23 11:58:53 UTC
please see screen shot from wpf 
the webadmin is not reporting correctly.
adding Simon to this.

Comment 4 Dafna Ron 2012-09-23 11:59:12 UTC
Created attachment 616093 [details]
screen shot

Comment 5 Ayal Baron 2012-09-23 15:14:17 UTC
(In reply to comment #3)
> please see screen shot from wpf 
> the webadmin is not reporting correctly.
> adding Simon to this.

No, wpf was reporting incorrectly.  The webadmin is actually presenting the *correct* size.
Your problem may be that we never preallocate on NFS though.

Comment 6 Simon Grinberg 2012-09-23 16:29:11 UTC
Reopening,

From user perspective this is a bug.
User does not care about last snapshot size, which is the value reported. User cares about the disk.
 
It really looks strange: 
Before the snapshot - reported size is 10G.
After the snapshot - reported size is 1G.

I can see this both in the VM's disks subtab and in the disks tab when *images is selected. While in the Storage tab -> VMs subtab you do see 11G distributed among the base Snapshot and the active one.

Comment 7 Tal Nisan 2012-09-30 09:49:59 UTC
http://gerrit.ovirt.org/#/c/8257/

Comment 9 Allon Mureinik 2012-09-30 10:59:56 UTC
Merged change id I96a45d426813bb296300e0871a206a3fdb24f52d

Comment 10 Dafna Ron 2012-10-07 09:13:12 UTC
verified on si20