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
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.
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).