Bug 968977 - engine: size report is incorrect after merge of LSM snapshot which ended with failure
engine: size report is incorrect after merge of LSM snapshot which ended with...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.2.0
x86_64 Linux
unspecified Severity high
: ---
: 3.4.0
Assigned To: Tal Nisan
Elad
storage
: Reopened
Depends On: 1072900
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-30 08:04 EDT by Dafna Ron
Modified: 2016-02-10 11:32 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-12 10:03:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
abaron: Triaged+


Attachments (Terms of Use)
logs (1.81 MB, application/x-gzip)
2013-05-30 08:04 EDT, Dafna Ron
no flags Details

  None (edit)
Description Dafna Ron 2013-05-30 08:04:53 EDT
Created attachment 754800 [details]
logs

Description of problem:

I blocked connectivity to the master domain which was the src domain from all my hosts during the cloneImageGroupSructure task. 
after I restored the storage I shut down the vm and deleted the LSM snapshot and I noticed that the size of the image is not reported correctly. 
looking at the db the size in the db is not corresponding to what we see in the vdsm. 

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

sf17.2
vdsm-4.10.2-22.0.el6ev.x86_64

How reproducible:

100%

Steps to Reproduce:
1. create two iscsi storage domains located on different servers
2. create a template and copy it to both domains
3. create a vm from the template on the master domain
4. run the vm and start a LSM on its disk 
5. when the task is sent to the vdsm block the master domain in both hosts using iptables
6. once the reconstruct finished, vm is paused and src domain becomes inactive, restore the connectivity to the master domain from both hosts. 
7. once the domain becomes active resume the vm
8. power off the vm 
9. restart vdsm on both hosts (due to bug 968933)
10. delete the LSM snapshot
11. select the vm tab -> disk sub tab -> look at the image size. 
12. run lvs on the host. 

Actual results:

engine is reporting Actual size 1GB while lvs shows that the size is 2.25g

Expected results:

we should report size correctly. 

Additional info: logs

[root@cougar01 ~]# lvs
  LV                                   VG                                   Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  540e5e0c-a604-47f7-a841-a98c15b2fed6 38755249-4bb3-4841-bf5b-05f4a521514d -wi-ao---   2.25g                                             
  f82a0d58-0791-4137-b1e6-22a8794acd2a 38755249-4bb3-4841-bf5b-05f4a521514d -wi-ao---   2.00g                                             
  ids                                  38755249-4bb3-4841-bf5b-05f4a521514d -wi-ao--- 128.00m                                             
  inbox                                38755249-4bb3-4841-bf5b-05f4a521514d -wi-a---- 128.00m                                             
  leases                               38755249-4bb3-4841-bf5b-05f4a521514d -wi-a----   2.00g                                             
  master                               38755249-4bb3-4841-bf5b-05f4a521514d -wi-a----   1.00g                                             
  metadata                             38755249-4bb3-4841-bf5b-05f4a521514d -wi-a---- 512.00m                                             
  outbox                               38755249-4bb3-4841-bf5b-05f4a521514d -wi-a---- 128.00m                                             
  58b5eeb4-310c-42dd-a8ec-e02efe938601 7414f930-bbdb-4ec6-8132-4640cbb3c722 -wi------   1.00g                                             
  f82a0d58-0791-4137-b1e6-22a8794acd2a 7414f930-bbdb-4ec6-8132-4640cbb3c722 -wi-a----   2.00g                                             
  ids                                  7414f930-bbdb-4ec6-8132-4640cbb3c722 -wi-ao--- 128.00m                                             
  inbox                                7414f930-bbdb-4ec6-8132-4640cbb3c722 -wi-a---- 128.00m                                             
  leases                               7414f930-bbdb-4ec6-8132-4640cbb3c722 -wi-a----   2.00g                                             
  master                               7414f930-bbdb-4ec6-8132-4640cbb3c722 -wi-a----   1.00g                                             
  metadata                             7414f930-bbdb-4ec6-8132-4640cbb3c722 -wi-a---- 512.00m                                             
  outbox                               7414f930-bbdb-4ec6-8132-4640cbb3c722 -wi-a---- 128.00m                                             
  lv_root                              vg0                                  -wi-ao--- 449.82g                                             
  lv_swap                              vg0                                  -wi-ao---  15.74g          

engine=# SELECT * from image_storage_domain_map ;
               image_id               |          storage_domain_id           
--------------------------------------+--------------------------------------
 f82a0d58-0791-4137-b1e6-22a8794acd2a | 38755249-4bb3-4841-bf5b-05f4a521514d
 f82a0d58-0791-4137-b1e6-22a8794acd2a | 7414f930-bbdb-4ec6-8132-4640cbb3c722
 540e5e0c-a604-47f7-a841-a98c15b2fed6 | 38755249-4bb3-4841-bf5b-05f4a521514d
(3 rows)

engine=# SELECT image_guid,size,image_group_id from images;
              image_guid              |    size     |            image_group_id            
--------------------------------------+-------------+--------------------------------------
 00000000-0000-0000-0000-000000000000 | 85899345920 | 
 f82a0d58-0791-4137-b1e6-22a8794acd2a | 16106127360 | cd5f0e01-8f73-4aa0-b837-b7f9bf4bc333
 540e5e0c-a604-47f7-a841-a98c15b2fed6 | 16106127360 | 923d4f8c-320e-4cc6-8783-0b937e011487
Comment 1 Daniel Erez 2013-07-09 04:47:53 EDT

*** This bug has been marked as a duplicate of bug 923864 ***
Comment 2 Dafna Ron 2013-07-09 07:24:21 EDT
Daniel, the scenrio and description of the two bugs are completely different 
before closing this as duplicate please make sure this bug's scenario is no longer reproduced.
Comment 4 Tal Nisan 2014-04-06 09:40:34 EDT
Unable to reproduce in 3.4 (most probably due to commit http://gerrit.ovirt.org/#/c/13243) - moving to ON_QA to attempt to reproduce, or close upstream (QA's decision).
Comment 5 Elad 2014-04-23 03:58:08 EDT
Blocking master domain leaves DC non-responsive (reconstruct doesn't function) due to https://bugzilla.redhat.com/show_bug.cgi?id=1072900
Comment 6 Elad 2014-05-20 09:31:38 EDT
Disk size is correctly reported by engine after the mentioned scenario.

Veified using av9.1
Comment 7 Itamar Heim 2014-06-12 10:03:51 EDT
Closing as part of 3.4.0

Note You need to log in before you can comment on or make changes to this bug.