Bug 878253 - system-config-lvm fails with thin LV - ExtentBlock.py - no attribute 'add_extent_block'
Summary: system-config-lvm fails with thin LV - ExtentBlock.py - no attribute 'add_ext...
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: system-config-lvm
Version: 6.3
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Marek Grac
QA Contact: Cluster QE
URL:
Whiteboard:
Keywords: Patch
Depends On:
Blocks: 1023565
TreeView+ depends on / blocked
 
Reported: 2012-11-19 23:32 UTC by Charles Butterfield
Modified: 2014-10-14 04:23 UTC (History)
10 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2014-10-14 04:23:57 UTC


Attachments (Terms of Use)
Patch to avoid immediate crash with thin LV and snapshots (16.62 KB, application/octet-stream)
2012-11-24 02:17 UTC, Charles Butterfield
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1403 normal SHIPPED_LIVE system-config-lvm bug fix update 2014-10-14 00:55:01 UTC

Description Charles Butterfield 2012-11-19 23:32:07 UTC
Description of problem: After creating thin LV, system-config-lvm aborts during startup.


Version-Release number of selected component (if applicable):
system-config-lvm.noarch            1.1.12-12.el6

How reproducible: Consistently reproducible


Steps to Reproduce:
1. create thin LV (see below)
2. launch system-config-lvm

Actual Results

system-config-lvm      # works fine
lvcreate -L 100G -T g2/pool
lvcreate  -T g2/pool -V 80G --name vimages
lvs                    # show new LV
  LV      VG   Attr     LSize   Pool Origin Data%  Move Log Copy%  Convert
  home    g1   -wi-ao--  15.62g
  root    g1   -wi-ao--  15.62g
  spare   g1   -wi-ao--  36.00g
  pool    g2   twi-a-tz 100.00g               0.00
  spare   g2   -wi-ao-- 515.00g
  swap    g2   -wi-a--- 100.50g
  vhome   g2   -wi-ao-- 100.00g
  vimages g2   Vwi-a-tz  80.00g pool          0.00

system-config-lvm      # fails with stacktrace
Traceback (most recent call last):
  File "/usr/sbin/system-config-lvm", line 172, in <module>
    runFullGUI()
  File "/usr/sbin/system-config-lvm", line 157, in runFullGUI
    blvm = baselvm(glade_xml, app)
  File "/usr/sbin/system-config-lvm", line 105, in __init__
    self.volume_tab_view = Volume_Tab_View(glade_xml, self.lvmm, self.main_win)
  File "/usr/share/system-config-lvm/Volume_Tab_View.py", line 133, in __init__
    self.prepare_tree()
  File "/usr/share/system-config-lvm/Volume_Tab_View.py", line 214, in prepare_tree
    self.model_factory.reload()
  File "/usr/share/system-config-lvm/lvm_model.py", line 168, in reload
    self.__query_LVs()
  File "/usr/share/system-config-lvm/lvm_model.py", line 526, in __query_LVs
    extent_block = ExtentBlock(pv, lv, ph_ext_beg, seg_size)
  File "/usr/share/system-config-lvm/ExtentBlock.py", line 14, in __init__
    self.__pv.add_extent_block(self)
AttributeError: 'NoneType' object has no attribute 'add_extent_block'


I have submitted a similar BZ for Fedora-17  - https://bugzilla.redhat.com/show_bug.cgi?id=878251

Comment 2 Charles Butterfield 2012-11-21 03:25:17 UTC
After some fiddling, I get a different failure.  I populated the thin LV, took a number of multisnap snapshots, then deleted the snapshots.

Here is the output of lvs --all and the crash from system-config-lvm

$ lvs --all
  LV            VG   Attr     LSize   Pool  Origin Data%  Move Log Copy%  Convert
  home          g1   -wi-ao--  15.62g
  root          g1   -wi-ao--  15.62g
  spare         g1   -wi-ao--  36.00g
  spare         g2   -wi-ao-- 515.00g
  swap          g2   -wi-a--- 100.50g
  vhome         g2   -wi-ao-- 100.00g
  vimages       g2   Vwi-aotz 399.00g vpool         15.16
  vpool         g2   twi-a-tz 399.00g               15.16
  [vpool_tdata] g2   Twi-aot- 399.00g
  [vpool_tmeta] g2   ewi-aot- 100.00m

[root@vh3] ~
$ system-config-lvm
Traceback (most recent call last):
  File "/usr/sbin/system-config-lvm", line 172, in <module>
    runFullGUI()
  File "/usr/sbin/system-config-lvm", line 157, in runFullGUI
    blvm = baselvm(glade_xml, app)
  File "/usr/sbin/system-config-lvm", line 105, in __init__
    self.volume_tab_view = Volume_Tab_View(glade_xml, self.lvmm, self.main_win)
  File "/usr/share/system-config-lvm/Volume_Tab_View.py", line 133, in __init__
    self.prepare_tree()
  File "/usr/share/system-config-lvm/Volume_Tab_View.py", line 214, in prepare_tree
    self.model_factory.reload()
  File "/usr/share/system-config-lvm/lvm_model.py", line 168, in reload
    self.__query_LVs()
  File "/usr/share/system-config-lvm/lvm_model.py", line 520, in __query_LVs
    ph_ext_beg = int(devs[0][idx+1:len(devs[0])-1])
ValueError: invalid literal for int() with base 10: ''

Comment 3 Charles Butterfield 2012-11-21 15:06:24 UTC
I took a look at the code last night and realized that there is zero support for the new multisnap LVs (pools and thinp volumes).  The change in error messages was solely due to a rename of the pool which changed the parsing order of the various LVs.

I tried to extend some of the attribute checking logic to just ignore the new LV types ("t" and "V"), but without a real understanding of the overall design, that became a game of whack-a-mole.

My immediate use case is to make the GUI tool usable for legacy VMs, while I create a few multisnap volumes (mainly for hourly snapshots of an origin LV holding all my VM images).  Does anybody with an understanding of the GUI architecture have suggestions on whether there is some simply way to "NO-OP" the new LVs, and if so, provide some suggestions?

Thanks!

Comment 4 Charles Butterfield 2012-11-21 15:08:23 UTC
OOPS in the above comment about my use case I meant "legacy LVs", NOT "legacy VMs" :-(

Comment 5 Zdenek Kabelac 2012-11-21 15:18:30 UTC
Yes, system-config-lvm is rather in maintenance mode, and new features are not added, thus system-config-lvm gets confused when new LV types are available.

Comment 6 Marek Grac 2012-11-22 12:41:13 UTC
@Charles:

I will try to fix it, so system-config-lvm won't crash and will be usable for supported volumes. Zdenek is right that we are in maintanance mode and this tool will be soon replaced by alternative which can keep track of dynamicity of development.

Comment 7 Charles Butterfield 2012-11-24 02:17:06 UTC
Created attachment 650755 [details]
Patch to avoid immediate crash with thin LV and snapshots

I tweaked the existing code a bit to the point where it will show the new thin LVs and both classic and new snapshots without crashing.  I took the approach of only rendering LVs on the GUI cylinder when they were the SOLE owner of some storage blocks.  Thus I inhibited rendering of thin LVs (regular or snapshots) as well as the thin pool LV (since it is just a holder for its two underlying LVs), but do render the two underlying <pool>_tdata and <pool>_tmeta LV's.

I did NOT suppress the listing of all of the LVs, just the space rendering on the GUI cylinder.

Note sure it that is in line with what you are planning, but it works for my needs.

I have attached a patch file (with some commented out debug print) in case it is useful.  This is my first foray into Python.  Please excuse any newbie goofiness.

Comment 8 Charles Butterfield 2012-11-24 02:22:13 UTC
I tried the above patches on my Fedora-17 system with system-config-lvm-1.1.18, but it was not successful, even though the 5 patched files are almost identical between 1.1.12 and 1.1.18.  The GUI comes up after emitting some error messages, then seems to hang.

So sad :-(

Comment 9 Marek Grac 2013-02-13 10:03:01 UTC
@Charles:

sorry for late response. 

Thin pools/volumes are not supported because this project is in maintaince mode only but it surely should not crash. Patch that fixes this was sent to upstream and will be part of next version. 

http://git.fedorahosted.org/cgit/system-config-lvm.git/commit/?id=97b353cc0469f6067f53117a9557d6750bd00dc2

Comment 18 errata-xmlrpc 2014-10-14 04:23:57 UTC
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.

http://rhn.redhat.com/errata/RHBA-2014-1403.html


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