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 619826 - [RFE] Need a way to determine if a particular block device is a logical volume
Summary: [RFE] Need a way to determine if a particular block device is a logical volume
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libguestfs
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 620861 (view as bug list)
Depends On: 619793
Blocks: 580461
TreeView+ depends on / blocked
 
Reported: 2010-07-30 16:08 UTC by Matthew Booth
Modified: 2010-11-10 21:03 UTC (History)
7 users (show)

Fixed In Version: libguestfs-1.2.7-1.23.el6
Doc Type: Enhancement
Doc Text:
Clone Of: 619793
: 636454 (view as bug list)
Environment:
Last Closed: 2010-11-10 21:03:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Backport new API is_lv from upstream development branch. (27.70 KB, patch)
2010-07-30 16:32 UTC, Richard W.M. Jones
no flags Details | Diff

Description Matthew Booth 2010-07-30 16:08:23 UTC
+++ This bug was initially created as a clone of Bug #619793 +++

Description of problem:
I need a robust, reliable way to determine if a particular block device is a logical volume when inspecting a guest. This rules out methods based on path name inspection, as these paths can be changed by configuration and vary between distributions.

My chosen solution to this problem is to stat every device returned by lvs(), and to stat the target device, and test if the major and minor numbers of the target appear in the list returned by lvs(). This avoid any issues relating to path names. However, it is complicated because stat() doesn't chroot, and therefore you can't stat a device node. I'm doing sh("stat...") to work round this, which is ugly.

I don't know what the best approach to this is. It could be a new is_lvm_device(dev), a change to the existing stat() api to work on device nodes, a new api to stat device nodes(), or something else.

However, I'm slightly concerned that this use case is quite esoteric. I can't think of any previous occasion using libguestfs or otherwise when I have been concerned to know whether or not a block device is a logical volume. The high-level api may be extremely under-used, meaning an implementation in virt-v2v is more appropriate.

Version-Release number of selected component (if applicable):
libguestfs-1.5.0-4.fc13.x86_64

--- Additional comment from rjones on 2010-07-30 11:40:48 EDT ---

Patch posted upstream:
https://www.redhat.com/archives/libguestfs/2010-July/msg00086.html

--- Additional comment from rjones on 2010-07-30 12:03:17 EDT ---

Pushed upstream:
http://git.annexia.org/?p=libguestfs.git;a=commitdiff;h=6280ac9b987c14f89749b4b4fdfec5a647567432

Matt, you'd better clone this bug for RHEL 6.

Comment 1 Richard W.M. Jones 2010-07-30 16:32:39 UTC
Created attachment 435600 [details]
Backport new API is_lv from upstream development branch.

This is the backported patch, with generated code.

Comment 2 Bill Nottingham 2010-07-30 16:41:44 UTC
Woudln't it be simpler to pull this from the udev database? It should know this in some way (and if it doesn't, *it* should be changed).

Comment 3 Richard W.M. Jones 2010-07-30 18:17:49 UTC
Bill, did you mean udev or blkid?  I can't see anything in udev about
this.  blkid doesn't currently contain this information either.  Could be
added though, although probably not for RHEL 6.0 ...

Comment 4 Richard W.M. Jones 2010-08-03 16:38:28 UTC
*** Bug 620861 has been marked as a duplicate of this bug. ***

Comment 5 Matthew Booth 2010-08-03 16:47:36 UTC
It should be simple to test this feature in guestfish. In a guest which has a logical volume called /dev/VolGroup00/LogVol00 (for example, rhel4u8-64b-pv-raw-intel), do:

guestfish -i /path/to/guest.img
><fs> is-lv /dev/VolGroup00/LogVol00
true
><fs> is-lv /dev/sda1
false

Comment 7 Richard W.M. Jones 2010-08-03 18:13:12 UTC
Patch is ready to go as soon as we get ACKs.  If it's ACKed now,
I can do a build this evening.

Comment 8 Matthew Booth 2010-08-04 09:43:55 UTC
We won't make Snapshot 10, so this will have to be Snapshot 11.

Comment 10 Jinxin Zheng 2010-08-06 10:22:50 UTC
Simple test,

guestfish
><fs> sparse test.img 100M
><fs> run
><fs> part-disk /dev/sda mbr
><fs> is-lv /dev/sda
false
><fs> is-lv /dev/sda1
false
><fs> pvcreate /dev/sda1
><fs> vgcreate vg1 /dev/sda1
><fs> lvcreate lv1 vg1 10
><fs> is-lv /dev/vg1/lv1 
true

working as expected.

Comment 11 releng-rhel@redhat.com 2010-11-10 21:03:14 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.


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