RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1085684 - Can we support wildcard with command vgremove?
Summary: Can we support wildcard with command vgremove?
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Peter Rajnoha
QA Contact: cluster-qe@redhat.com
Steven J. Levine
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-09 06:36 UTC by XiaoNi
Modified: 2021-09-03 12:37 UTC (History)
11 users (show)

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.
Clone Of:
Environment:
Last Closed: 2015-11-19 12:45:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2147 0 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2015-11-19 11:11:07 UTC

Description XiaoNi 2014-04-09 06:36:06 UTC 
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.

Version-Release number of selected component (if applicable):
[root@ibm-z10-40 grow-size-change]# vgremove --version
  LVM version:     2.02.105(2)-RHEL7 (2014-03-26)
  Library version: 1.02.84-RHEL7 (2014-03-26)
  Driver version:  4.27.0


How reproducible:
100%

Steps to Reproduce:
[root@ibm-z10-40 grow-size-change]# vgremove -f testvg[1-8]
  Volume group name testvg[1-8] has invalid characters
  Skipping volume group testvg[1-8]
[root@ibm-z10-40 grow-size-change]# pvremove /dev/loop[0-7]
  Labels on physical volume "/dev/loop0" successfully wiped
  Labels on physical volume "/dev/loop1" successfully wiped
  Labels on physical volume "/dev/loop2" successfully wiped
  Labels on physical volume "/dev/loop3" successfully wiped
  Labels on physical volume "/dev/loop4" successfully wiped
  Labels on physical volume "/dev/loop5" successfully wiped
  Labels on physical volume "/dev/loop6" successfully wiped
  Labels on physical volume "/dev/loop7" successfully wiped



Actual results:
The command failed

Expected results:
Vgremove can support wildcard as pvremove do.


Additional info:
Comment 2 Peter Rajnoha 2014-04-09 08:50:44 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...
Comment 6 XiaoNi 2014-04-10 03:17:53 UTC 
(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
Comment 7 Alasdair Kergon 2014-04-10 11:23:02 UTC 
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.
Comment 8 XiaoNi 2014-04-11 06:52:42 UTC 
(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
Comment 10 Peter Rajnoha 2014-11-26 08:01:22 UTC 
We're just working on this, it's not in 7.1 yet, moving to 7.2.
Comment 11 Peter Rajnoha 2015-01-06 09:11:35 UTC 
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)
Comment 12 Peter Rajnoha 2015-02-10 15:18:37 UTC 
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...
Comment 14 Nenad Peric 2015-04-14 12:51:51 UTC 
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.
Comment 16 Corey Marthaler 2015-08-24 22:51:47 UTC 
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
Comment 20 errata-xmlrpc 2015-11-19 12:45:23 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.

https://rhn.redhat.com/errata/RHBA-2015-2147.html
Note You need to log in before you can comment on or make changes to this bug.