Bug 1085684
| Summary: | Can we support wildcard with command vgremove? | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | XiaoNi <xni> |
| Component: | lvm2 | Assignee: | Peter Rajnoha <prajnoha> |
| lvm2 sub component: | Command-line tools | QA Contact: | cluster-qe <cluster-qe> |
| Status: | CLOSED ERRATA | Docs Contact: | Steven J. Levine <slevine> |
| Severity: | unspecified | ||
| Priority: | unspecified | CC: | agk, cmarthal, heinzm, jbrassow, msnitzer, nperic, prajnoha, prockai, slevine, thornber, zkabelac |
| Version: | 7.1 | ||
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | lvm2-2.02.125-1.el7 | Doc Type: | Enhancement |
| Doc Text: |
Enhancements to LVM selection criteria
The Red Hat Enterprise Linux 7.2 release supports several enhancements to LVM selection criteria. Previously, it was possible to use selection criteria only for reporting commands; LVM now supports selection criteria for several LVM processing commands as well. Additionally, there are several changes in this release to provide better support for time reporting fields and selection.
For information on the implementation of these new features, see the "LVM Selection Criteria" appendix in the Logical Volume Administration manual.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-19 12:45:23 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
XiaoNi
2014-04-09 06:36:06 UTC
(In reply to XiaoNi from comment #0) > Description of problem: > Because I usually create and delete many vg groups. Certainly we can do it > with script. But I see pvremove supports "pvremove /dev/loop[0-7]" and > vgremove doesn't support it. If we can support this by vgremove, I think > it's a good thing. The bracket expansion is actually a shell feature, not LVM tool feature. We don't support expansions yet. However, we have FutureFeature bug #867376 which is about providing criteria based reporting and exection in general. As for the reporting part, the patchset is almost ready - this filters out lines on output that do not match the condition supplied. I've rebased that and added some extensions to the original patchese but it's not yet upstream as it still needs some finishing (the original patchset is actually an old patchset proposed long time ago by Jun'ichi Nomura here http://www.redhat.com/archives/dm-devel/2007-April/msg00025.html so I'm trying to revive it). This basic idea could be reused for conditional processing as well as opposed to reporting (which means that only the volumes that match the condition will be processed - for example "remove all snapshot LVs having 'abc' prefix in its name and larger than X GB" and written in the form of standardized condition). But we haven't done any design yet here. The request reported here could be satisfied with a solution to bug #867376. Though bug #867376 one has a low priority at the moment... (In reply to Peter Rajnoha from comment #2) > (In reply to XiaoNi from comment #0) > > Description of problem: > > Because I usually create and delete many vg groups. Certainly we can do it > > with script. But I see pvremove supports "pvremove /dev/loop[0-7]" and > > vgremove doesn't support it. If we can support this by vgremove, I think > > it's a good thing. > > The bracket expansion is actually a shell feature, not LVM tool feature. We > don't support expansions yet. > > However, we have FutureFeature bug #867376 which is about providing criteria > based reporting and exection in general. As for the reporting part, the > patchset is almost ready - this filters out lines on output that do not > match the condition supplied. I've rebased that and added some extensions to > the original patchese but it's not yet upstream as it still needs some > finishing (the original patchset is actually an old patchset proposed long > time ago by Jun'ichi Nomura here > http://www.redhat.com/archives/dm-devel/2007-April/msg00025.html so I'm > trying to revive it). Thanks for the quick reply. It's a wonderful idear. It can give more availability. > > This basic idea could be reused for conditional processing as well as > opposed to reporting (which means that only the volumes that match the > condition will be processed - for example "remove all snapshot LVs having > 'abc' prefix in its name and larger than X GB" and written in the form of > standardized condition). But we haven't done any design yet here. > > The request reported here could be satisfied with a solution to bug #867376. > Though bug #867376 one has a low priority at the moment... Yes, it's not urgent and we can wait for the finish of bug #867376. Thanks Xiao You can also add tags to groups of LVs (--addtag on lvcreate or lvchange) and then apply an operation (like vgremove) to all LVs with the tag (@tagname). See man 8 lvm. (In reply to Alasdair Kergon from comment #7) > You can also add tags to groups of LVs (--addtag on lvcreate or lvchange) > and then apply an operation (like vgremove) to all LVs with the tag > (@tagname). See man 8 lvm. Hi Alasdair Thanks for the idear! It's an interesing feature. I have tried it, it works well. If the command can support it rather than use -addtag, I think it's also a good choice. Certainly it doesn't affect the data validity. Xiao We're just working on this, it's not in 7.1 yet, moving to 7.2. Current development code is in this branch: https://git.fedorahosted.org/cgit/lvm2.git/log/?h=dev-prajnoha-tool-select (extending support for -S|--select in lvm processing tools besides existing support in lvm reporting tools) The dev-prajnoha-tool-select devel branch is now merged in master. Currently, the -S/--select is supported for these commands: vgremove and lvremove (the exact case requested here in this bz) vgchange, lvchange and pvchange vgdisplay, lvdisplay and pvdisplay vgexport and vgimport Scheduled for upcoming lvm2 v2.02.117. We'll be adding support for -S/--select in other commands gradually... If you have sequential VG names (ie. vg1, vg2, vg3...) you can use a different shell expansion which expands the command line with all the possible combinations stated inside the curly braces, and it works out of the box:
[root@tardis-02 ~]# vgremove --yes vg{1..3}
Volume group "vg1" successfully removed
Volume group "vg2" successfully removed
Volume group "vg3" successfully removed
[root@tardis-02 ~]#
However, the -S/--select will add deeper scanning such as removal of VGs which contain specific LVs with more complicated names for example, which is then much faster than bash through the built-in LVM select options.
Marking verified in the latest rpms. 3.10.0-306.el7.x86_64 lvm2-2.02.128-1.el7 BUILT: Tue Aug 18 03:45:17 CDT 2015 lvm2-libs-2.02.128-1.el7 BUILT: Tue Aug 18 03:45:17 CDT 2015 lvm2-cluster-2.02.128-1.el7 BUILT: Tue Aug 18 03:45:17 CDT 2015 device-mapper-1.02.105-1.el7 BUILT: Tue Aug 18 03:45:17 CDT 2015 device-mapper-libs-1.02.105-1.el7 BUILT: Tue Aug 18 03:45:17 CDT 2015 device-mapper-event-1.02.105-1.el7 BUILT: Tue Aug 18 03:45:17 CDT 2015 device-mapper-event-libs-1.02.105-1.el7 BUILT: Tue Aug 18 03:45:17 CDT 2015 device-mapper-persistent-data-0.5.5-1.el7 BUILT: Thu Aug 13 09:58:10 CDT 2015 cmirror-2.02.128-1.el7 BUILT: Tue Aug 18 03:45:17 CDT 2015 sanlock-3.2.4-1.el7 BUILT: Fri Jun 19 12:48:49 CDT 2015 sanlock-lib-3.2.4-1.el7 BUILT: Fri Jun 19 12:48:49 CDT 2015 lvm2-lockd-2.02.128-1.el7 BUILT: Tue Aug 18 03:45:17 CDT 2015 Made sure that --select "wildcard" works with the following cmds. [root@host-111 ~]# lvs -a -o +devices LV VG Attr LSize Devices lva vga -wi-a----- 100.00m /dev/sda1(0) lvb vgb -wi-a----- 100.00m /dev/sdb1(0) lvc vgc -wi-a----- 100.00m /dev/sdc1(0) lvd vgd -wi-a----- 100.00m /dev/sdd1(0) lve vge -wi-a----- 100.00m /dev/sde1(0) lvf vgf -wi-a----- 100.00m /dev/sdf1(0) lvg vgg -wi-a----- 100.00m /dev/sdg1(0) lvh vgh -wi-a----- 100.00m /dev/sdh1(0) [root@host-111 ~]# lvchange -an -S 'lv_name=~lv' [root@host-111 ~]# lvs -a -o +devices LV VG Attr LSize Devices lva vga -wi------- 100.00m /dev/sda1(0) lvb vgb -wi------- 100.00m /dev/sdb1(0) lvc vgc -wi------- 100.00m /dev/sdc1(0) lvd vgd -wi------- 100.00m /dev/sdd1(0) lve vge -wi------- 100.00m /dev/sde1(0) lvf vgf -wi------- 100.00m /dev/sdf1(0) lvg vgg -wi------- 100.00m /dev/sdg1(0) lvh vgh -wi------- 100.00m /dev/sdh1(0) [root@host-111 ~]# lvchange -ay -S 'lv_name=~lv' [root@host-111 ~]# lvs -a -o +devices LV VG Attr LSize Devices lva vga -wi-a----- 100.00m /dev/sda1(0) lvb vgb -wi-a----- 100.00m /dev/sdb1(0) lvc vgc -wi-a----- 100.00m /dev/sdc1(0) lvd vgd -wi-a----- 100.00m /dev/sdd1(0) lve vge -wi-a----- 100.00m /dev/sde1(0) lvf vgf -wi-a----- 100.00m /dev/sdf1(0) lvg vgg -wi-a----- 100.00m /dev/sdg1(0) lvh vgh -wi-a----- 100.00m /dev/sdh1(0) [root@host-111 ~]# pvchange --addtag foo -S 'pv_name=~sd' Physical volume "/dev/sda1" changed Physical volume "/dev/sdf1" changed Physical volume "/dev/sdh1" changed Physical volume "/dev/sdb1" changed Physical volume "/dev/sde1" changed Physical volume "/dev/sdc1" changed Physical volume "/dev/sdd1" changed Physical volume "/dev/sdg1" changed 8 physical volumes changed / 0 physical volumes not changed [root@host-111 ~]# pvs -a -o +pv_tags PV VG Fmt Attr PSize PFree PV Tags /dev/sda1 vga lvm2 a-- 24.99g 24.89g foo /dev/sdb1 vgb lvm2 a-- 24.99g 24.89g foo /dev/sdc1 vgc lvm2 a-- 24.99g 24.89g foo /dev/sdd1 vgd lvm2 a-- 24.99g 24.89g foo /dev/sde1 vge lvm2 a-- 24.99g 24.89g foo /dev/sdf1 vgf lvm2 a-- 24.99g 24.89g foo /dev/sdg1 vgg lvm2 a-- 24.99g 24.89g foo /dev/sdh1 vgh lvm2 a-- 24.99g 24.89g foo [root@host-111 ~]# vgchange -an -S 'vg_name=~vg' 0 logical volume(s) in volume group "vga" now active 0 logical volume(s) in volume group "vgf" now active 0 logical volume(s) in volume group "vgh" now active 0 logical volume(s) in volume group "vgb" now active 0 logical volume(s) in volume group "vge" now active 0 logical volume(s) in volume group "vgc" now active 0 logical volume(s) in volume group "vgd" now active 0 logical volume(s) in volume group "vgg" now active [root@host-111 ~]# vgexport -S 'vg_name=~vg' Volume group "vga" successfully exported Volume group "vgf" successfully exported Volume group "vgh" successfully exported Volume group "vgb" successfully exported Volume group "vge" successfully exported Volume group "vgc" successfully exported Volume group "vgd" successfully exported Volume group "vgg" successfully exported [root@host-111 ~]# vgimport -S 'vg_name=~vg' Volume group "vga" successfully imported Volume group "vgf" successfully imported Volume group "vgh" successfully imported Volume group "vgb" successfully imported Volume group "vge" successfully imported Volume group "vgc" successfully imported Volume group "vgd" successfully imported Volume group "vgg" successfully imported [root@host-111 ~]# vgchange -ay -S 'vg_name=~vg' 1 logical volume(s) in volume group "vga" now active 1 logical volume(s) in volume group "vgf" now active 1 logical volume(s) in volume group "vgh" now active 1 logical volume(s) in volume group "vgb" now active 1 logical volume(s) in volume group "vge" now active 1 logical volume(s) in volume group "vgc" now active 1 logical volume(s) in volume group "vgd" now active 1 logical volume(s) in volume group "vgg" now active 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-2015-2147.html |