Bug 1117385
| Summary: | LUN resize not picked up by multipath on VDSM refresh | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Federico Simoncelli <fsimonce> |
| Component: | vdsm | Assignee: | Fred Rolland <frolland> |
| Status: | CLOSED ERRATA | QA Contact: | Elad <ebenahar> |
| Severity: | urgent | Docs Contact: | |
| Priority: | high | ||
| Version: | 3.5.0 | CC: | amureini, bazulay, bmarzins, lpeer, mkalinin, pzhukov, scohen, yeylon |
| Target Milestone: | ovirt-3.6.0-rc | ||
| Target Release: | 3.6.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | vdsm-4.17.0-1198.git6ede99a | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-03-09 19:23:06 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: | |||
|
Description
Federico Simoncelli
2014-07-08 14:44:07 UTC
More info: Kernel 2.6.32-431.20.3.el6.x86_64 device-mapper-multipath-0.4.9-72.el6_5.3.x86_64 device-mapper-1.02.79-8.el6.x86_64 Ben, can you take a look at this? In https://bugzilla.redhat.com/show_bug.cgi?id=1078879#c18 you wrote: # Multipath -r really isn't useful for much of anything, and It seemed to be required so multipath pick changes in the lun size. Maybe we did not understand your recommendation? I'm confused. Running # service multipathd reload should pick up a resize just as well as running "multipath -r". Is that not what you are seeing? (In reply to Ben Marzinski from comment #3) > I'm confused. Running > > # service multipathd reload > > should pick up a resize just as well as running "multipath -r". Is that not > what > you are seeing? Are you saying that multipathd is not automatically picking up lun resizes and we have either run multipathd reload or "multipath -r"? Yes. You need to manually run # service multipathd reload or # multipath -r Running # service multipathd reload is generally better, since running # multipath -r will not update anything in the daemon except a change in the device table. However, in the case of a device resize, that's all that is changing, so # multipath -r should work fine. We cannot use multipath -r because it may cause a segfault in multipathd (bug 1080052). This will be fixed in el6.6. So the only option left is running "vdsm-tool service-reload multipathd" when we run today "multipath". (In reply to Nir Soffer from comment #6) > We cannot use multipath -r because it may cause a segfault in multipathd > (bug 1080052). This will be fixed in el6.6. > > So the only option left is running "vdsm-tool service-reload multipathd" > when we run today "multipath". Pushing out to RHEV 3.6 to consume the RHEL 6.6 fix. For RHEV 3.6.0 we'll no longer support RHEL6, so we can move forward with this BZ. *** Bug 1223456 has been marked as a duplicate of this bug. *** As part of the RFE described in bug 609689, multipath should resize luns when VDSM issues ConnectStorageServer, or manually when you resize a lun via the engine. That should be sufficient to cover this flow. LUN resize is now picked up by VDSM and recognized by engine during getDeviceList as part of 609689. Steps: - Created and exposed a 43G LUN to the host sdax 67:16 0 43G 0 disk └─360060160f4a0300002939236a8e6e411 253:67 0 43G 0 mpath - Created a storage domain out of the LUN - Resized the LUN from the storage server to 50G - Edited the storage domain. Via Webadmin, the option to increase the size of the storage domain resides on the resized LUN was available. Resized and confirmed. - Created successfully a 40G preallocated virtual disk on this domain. Multipath now shows the new size of the LUN (50G): sdax 67:16 0 43G 0 disk └─360060160f4a0300002939236a8e6e411 253:67 0 43G 0 mpath Verified using ovirt-3.6.0-5 Sorry, copy-paste issue, here is the updated lsblk output for this LUN: sdax 67:16 0 50G 0 disk └─360060160f4a0300002939236a8e6e411 253:67 0 50G 0 mpath Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0362.html |