Bug 1252060
| Summary: | LV underlying thin-provisioned disk not extended | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | David Jaša <djasa> | 
| Component: | vdsm | Assignee: | Nir Soffer <nsoffer> | 
| Status: | CLOSED DUPLICATE | QA Contact: | Aharon Canan <acanan> | 
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.6.0 | CC: | amureini, bazulay, djasa, ecohen, gklein, lpeer, lsurette, nsoffer, ycui, yeylon | 
| Target Milestone: | ovirt-3.6.3 | ||
| Target Release: | 3.6.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | storage | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-08-13 14:21:32 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: | |||
Created attachment 1061136 [details]
vdsm.log from the host where VM was running
    Created attachment 1061137 [details]
vdsm.log from SPM host
    The extend request is sent properly(?) by the HSM and received properly(?) by the SPM. However, the requested extend size seems to be wrong. E.g.:
6d2d15df-4fc5-46cb-b3cb-afc89ae2011d::DEBUG::2015-08-10 16:15:02,789::storage_mailbox::146::Storage.SPM.Messages.Extend::(processRequest) processRequest, payload:'1xtnd?\xf3>\xc2`\x99\xfc\x94\xc2G\xf0\xbe[\x92\xe9Yz<\x0b(\xa6\x03\x82\xb5\xd1E\xcc\xff\xac\xd4`\x87000000000000040000000000000'
6d2d15df-4fc5-46cb-b3cb-afc89ae2011d::INFO::2015-08-10 16:15:02,789::storage_mailbox::161::Storage.SPM.Messages.Extend::(processRequest) processRequest: extending volume 8760d4ac-ffcc-45d1-b582-03a6280b3c7a in domain 59e9925b-bef0-47c2-94fc-9960c23ef33f (pool 00000001-0001-0001-0001-0000000001a7) to size 1024
6d2d15df-4fc5-46cb-b3cb-afc89ae2011d::DEBUG::2015-08-10 16:15:02,790::lvm::291::Storage.Misc.excCmd::(cmd) /usr/bin/sudo -n /usr/sbin/lvm lvextend --config ' devices { preferred_names = ["^/dev/mapper/"] ignore_suspended_devices=1 write_cache_state=0 disable_after_error_count=3 obtain_device_list_from_udev=0 filter = [ '\''a|/dev/mapper/3600c0ff0001592c40a51125201000000|'\'', '\''r|.*|'\'' ] }  global {  locking_type=1  prioritise_write_locks=1  wait_for_locks=1  use_lvmetad=0 }  backup {  retain_min = 50  retain_days = 0 } ' --autobackup n --size 1024m 59e9925b-bef0-47c2-94fc-9960c23ef33f/8760d4ac-ffcc-45d1-b582-03a6280b3c7a (cwd None)
6d2d15df-4fc5-46cb-b3cb-afc89ae2011d::DEBUG::2015-08-10 16:15:02,884::lvm::291::Storage.Misc.excCmd::(cmd) FAILED: <err> = "  WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!\n  New size (8 extents) matches existing size (8 extents)\n  Run `lvextend --help' for more information.\n"; <rc> = 3
(There are several messages like this repeating throughout the log)
Nir - can you please take a look?
Thanks!
    Nir, as per our talk, could this be a duplicate of bug 1251008? To verify that this is indeed a dup of bug 1251008, please try the patch attached to that bug. (In reply to Nir Soffer from comment #5) > To verify that this is indeed a dup of bug 1251008, please try the patch > attached to that bug. The patch makes LV extension work (In reply to David Jaša from comment #6) Thanks for testing this David. Based on comment 6, closing as duplicate. *** This bug has been marked as a duplicate of bug 1251008 ***  | 
Created attachment 1061135 [details] engine.log Description of problem: LV underlying thin-provisioned disk not extended Version-Release number of selected component (if applicable): 3.6.0-5 How reproducible: always on this setup Steps to Reproduce: 1. create a VM with thin-provisioned disk on iSCSI domain 2. install OS in the VM 3. Actual results: VM gets paused because the underlying LV doesn't get extended Expected results: LV hosting VM disk gets extended and VM keeps running Additional info: VM UUID: 5f7ad6e0-3e55-4563-b0cc-c62179c07654 Disk UUID: 8760d4ac-ffcc-45d1-b582-03a6280b3c7a VG UUID: 59e9925b-bef0-47c2-94fc-9960c23ef33f The storage domain was created by fedora hosts, however now is used by RHEL 7 (7.2) hosts