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 1398087 - libvirt client virsh pool-define-as build in help mismatches actual usage
Summary: libvirt client virsh pool-define-as build in help mismatches actual usage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.3
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: John Ferlan
QA Contact: jiyan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-24 05:47 UTC by Sage Grigull
Modified: 2017-08-01 23:59 UTC (History)
7 users (show)

Fixed In Version: libvirt-3.2.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 17:19:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1846 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2017-08-01 18:02:50 UTC

Description Sage Grigull 2016-11-24 05:47:15 UTC
Description of problem:
the arguments to virsh pool-define-as are unclear.

I wanted to (re)create a storage pool called default though with a specific pre-created volume.


a) use the options as supplied from the build-in help 'virsh pool-define-as --help'

```
# virsh pool-define-as --help
  NAME
    pool-define-as - define a pool from a set of args

  SYNOPSIS
    pool-define-as <name> <type> [--print-xml] [--source-host <string>] [--source-path <string>] [--source-dev <string>] [--source-name <string>] [--target <string>] [--source-format <string>] [--auth-type <string>] [--auth-username <string>] [--secret-usage <string>] [--adapter-name <string>] [--adapter-wwnn <string>] [--adapter-wwpn <string>] [--adapter-parent <string>]

  DESCRIPTION
    Define a pool.

  OPTIONS
    [--name] <string>  name of the pool
    [--type] <string>  type of the pool
    --print-xml      print XML document, but don't define/create
    --source-host <string>  source-host for underlying storage
    --source-path <string>  source path for underlying storage
    --source-dev <string>  source device for underlying storage
    --source-name <string>  source name for underlying storage
    --target <string>  target for underlying storage
    --source-format <string>  format for underlying storage
    --auth-type <string>  auth type to be used for underlying storage
    --auth-username <string>  auth username to be used for underlying storage
    --secret-usage <string>  auth secret usage to be used for underlying storage
    --adapter-name <string>  adapter name to be used for underlying storage
    --adapter-wwnn <string>  adapter wwnn to be used for underlying storage
    --adapter-wwpn <string>  adapter wwpn to be used for underlying storage
    --adapter-parent <string>  adapter parent to be used for underlying storage
```

create the volume using:
# virsh pool-define-as --name default --type logical --target /dev/rhel_ppc-hv-01
Pool default defined


[root@ppc-hv-01 network-scripts]# virsh pool-dumpxml default
<pool type='logical'>
  <name>default</name>
  <uuid>747501ef-544f-492f-91fc-3db68986c21a</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <name>default</name>
    <format type='unknown'/>
  </source>
  <target>
    <path>/dev/default</path>
  </target>
</pool>

a1)  the path is wring, it should be '/dev/rhel_ppc-hv-01'
a2)  source element <name>default</name> should be absent

---

b) use the options documented at [1].  This runs vunter to what the build in help describes.


# virsh pool-define-as default logical - - - /dev/libvirt_lvm
Pool default defined

[root@ppc-hv-01 network-scripts]# virsh pool-dumpxml default
<pool type='logical'>
  <name>default</name>
  <uuid>2acee500-766c-4a49-bf30-cf4668e44a7a</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <device path='-'/>
    <name>/dev/libvirt_lvm</name>
    <format type='lvm2'/>
  </source>
  <target>
    <path>/dev/dev/libvirt_lvm</path>
  </target>
</pool>

b1) the source element is defined but should be absent in this case.
b2) this method required excatly one source element.  LVM supports volumes on multiple devices.

[2] suggests that the source options should not be required.  Is this true for this version of libvirt/virsh ?



Version-Release number of selected component (if applicable):
libvirt-client-2.0.0-10.el7.ppc64le

How reproducible:
described above

Steps to Reproduce:
described above

Actual results:
described above

Expected results:
ability to create a logical volume based storage pools of desired name without requireing to set exactly one source device (either 0 or more) and desired target name




Additional info:
[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-LVM_based_storage_pools.html
[2] https://libvirt.org/storage.html#StorageBackendLogical

Comment 1 Sage Grigull 2016-11-24 05:51:34 UTC
I should be clearer about what I am trying to achieve.

My goal is to setup a default storage pool based on a volume group name as enumerated by ansible.  Therefore I would prefer to not have to mangle xml files on the target to achieve this.

Comment 3 John Ferlan 2017-03-25 12:22:24 UTC
Sorry this has taken way too long for any kind of response.

There's perhaps a few things about a libvirt logical pool that are "less than well described" in the virsh help and/or man page. Some of that is due to space and some of that is due to the uniqueness of the pool...

First and foremost is that the '--name' that you select must match the volume group name as that's how the storage pool maps to the volume group for which it is managing. I will generate a patch to alter the man page to be a bit more "explicit".

Thus, for your "a)" example, providing "default" means the logical storage pool would be expecting a volume group name "default" that uses "/dev/default". 

As an aside, the http://libvirt.org/storage.html#StorageBackendLogical description indicates: "For a pre-defined LVM volume group, simply providing the group name is sufficient"...

So a 'virsh pool-define-as --name rhel_ppc-hv-01 --type logical' would have done what you wanted.  

Additionally, the http://libvirt.org/formatstorage.html indicates within the "Target elements" description that "For logical and zfs pool types, a provided value is ignored and a default path generated."  The default path for logical being a combination of "/dev/" + source name (e.g. in case 'a)' rhel_ppc-hv-01).

These two pieces of information I'll add to the virsh man page.

With respect to your "b)" command:

  > virsh pool-define-as default logical - - - /dev/libvirt_lvm

due to how virsh processes arguments positionally on the command line, that means the three dashes ('-') equate to arguments --source-host, --source-path, and --source-dev while the /dev/libvirt_lvm equates to the --source-name as seen the generated XML using a --print-xml option:

<pool type='logical'>
  <name>default</name>
  <source>
    <host name='-'/>
    <dir path='-'/>
    <device path='-'/>
    <name>/dev/libvirt_lvm</name>
  </source>
</pool>


NOTE: As noted on http://libvirt.org/formatstorage.html, a logical pool does not process the "--source-host" and "--source-path" arguments

BTW: the --print-xml is incorrectly placed in the man page and that will also be fixed with my patch.

Also of note that the "name" doesn't match the "--source-name" (something that can also be fixed) nor does the name match what I assume is a "libvirt_lvm" group name.

Finally w/r/t "source element" - I assume you mean "--source-dev". The "--source-dev" is *only* necessary if you're building the pool; otherwise, providing the --source-name (or just the 'name') is sufficient (again the reference is the driver description http://libvirt.org/storage.html#StorageBackendLogical).

I have posted a patch to address the various issues described in this bz including one more not quite mentioned, but worthy of addition to generate the 'default' format type for the logical pool if not provided:

https://www.redhat.com/archives/libvir-list/2017-March/msg01227.html

Comment 4 John Ferlan 2017-03-27 18:36:50 UTC
Mentioned changes are now pushed upstream:

commit ca4515d2639057020c749470f390fe1f5981e91e
Author: John Ferlan <jferlan>
Date:   Sat Mar 25 08:07:36 2017 -0400

    storage: Better describe logical pool creation/definition parameters
...


$ git describe ca4515d2639057020c749470f390fe1f5981e91e
v3.1.0-393-gca4515d
$

Comment 5 Ján Tomko 2017-03-28 07:51:51 UTC
A revert of mentioned changes has been proposed upstream:
https://www.redhat.com/archives/libvir-list/2017-March/msg01416.html

Comment 6 Ján Tomko 2017-03-28 11:20:57 UTC
The docs changed are merged upstream as of:
commit 0b7ec61bcc8ff86299ce700526de0f400e41f49f
Author:     John Ferlan <jferlan>
CommitDate: 2017-03-28 13:19:47 +0200

    storage: Better describe logical pool creation/definition parameters
    
git describe: v3.2.0-rc1-11-g0b7ec61

Comment 8 jiyan 2017-05-26 04:53:47 UTC
some explains you gave out as follows:
>First and foremost is that the '--name' that you select must match the volume group name as that's how the storage pool maps to the volume group for 
>which it is managing. I will generate a patch to alter the man page to be a bit more "explicit".
>Thus, for your "a)" example, providing "default" means the logical storage pool would be expecting a volume group name "default" that uses >"/dev/default". 
>So a 'virsh pool-define-as --name rhel_ppc-hv-01 --type logical' would have done what you wanted.  

If I execute the command "virsh pool-define-as --name rhel_ppc-hv-01 --type logical", however there does not exist "rhel_ppc-hv-01" among the results that returned by the command "vgs",
under these circumstances, the command "virsh pool-define-as --name rhel_ppc-hv-01 --type logical" can execute successfully, but I can not start or delete the pool "rhel_ppc-hv-01".
So whether there is a necessary to do some dectect about "--name" and the "volume group",to confirm whether the volume group exists?

The testing steps as follows:
# vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  rhel   1   1   0 wz--n- 250.00g    0 
  vg01   1   1   0 wz--n-  10.00g    0 

# virsh pool-define-as --name vg --type logical
Pool vg defined

# virsh pool-dumpxml vg
<pool type='logical'>
  <name>vg</name>
  <uuid>2256da4d-6a6b-44e8-98e1-77b7c0211b97</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <name>vg</name>
    <format type='lvm2'/>
  </source>
  <target>
    <path>/dev/vg</path>
  </target>
</pool>

# virsh pool-list --all |grep vg
 vg                   inactive   no 

# virsh pool-start vg
error: Failed to start pool vg
error: unsupported configuration: cannot find logical volume group name 'vg'

# virsh pool-delete vg
error: Failed to delete pool vg
error: internal error: Child process (/usr/sbin/vgremove -f vg) unexpected exit status 5: 2017-05-25 11:19:19.846+0000: 5427: debug : virFileClose:110 : Closed fd 26
2017-05-25 11:19:19.846+0000: 5427: debug : virFileClose:110 : Closed fd 28
2017-05-25 11:19:19.846+0000: 5427: debug : virFileClose:110 : Closed fd 24
  Volume group "vg" not found
  Cannot process volume group vg

Comment 9 John Ferlan 2017-05-26 14:29:25 UTC
(In reply to jiyan from comment #8)
> some explains you gave out as follows:
> >First and foremost is that the '--name' that you select must match the volume group name as that's how the storage pool maps to the volume group for 
> >which it is managing. I will generate a patch to alter the man page to be a bit more "explicit".
> >Thus, for your "a)" example, providing "default" means the logical storage pool would be expecting a volume group name "default" that uses >"/dev/default". 
> >So a 'virsh pool-define-as --name rhel_ppc-hv-01 --type logical' would have done what you wanted.  
> 
> If I execute the command "virsh pool-define-as --name rhel_ppc-hv-01 --type
> logical", however there does not exist "rhel_ppc-hv-01" among the results
> that returned by the command "vgs",
> under these circumstances, the command "virsh pool-define-as --name
> rhel_ppc-hv-01 --type logical" can execute successfully, but I can not start
> or delete the pool "rhel_ppc-hv-01".
> So whether there is a necessary to do some dectect about "--name" and the
> "volume group",to confirm whether the volume group exists?
> 

I think this is your question/needsinfo...  The short answer is no.

The longer explanation involves a bit of show and tell... So let's follow the logic:

# virsh pool-define-as --name foobar --type logical
Pool foobar defined

# virsh pool-dumpxml foobar
<pool type='logical'>
  <name>foobar</name>
  <uuid>9ed4ec6f-9a97-440a-84be-a0a86b0353a6</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <name>foobar</name>
    <format type='lvm2'/>
  </source>
  <target>
    <path>/dev/foobar</path>
  </target>
</pool>

#

There's "nothing" in the "define" processing that says /dev/foobar needs to exist. Just that we want to define it.  Similar to other define commands, there's nothing that says/validates that a resource that you want to define is currently available.

The antecedent to pool-define[-as] is pool-undefine, not pool-destroy or pool-delete.

When it comes to the "pool-delete" or "pool-destroy" - well those operations are indicating exactly the same that pool-create or pool-start of a pool-define would indicate. Some resource that the pool was expecting to be available doesn't exist, so they fail properly.

FWIW: If this were a pool-create-as operation:

# virsh pool-create-as --name foobar --type logical
error: Failed to create pool foobar
error: unsupported configuration: cannot find logical volume group name 'foobar'

#

Which requires the "foobar" resource to be available because we're going to use it.

Hopefully this makes sense and hopefully answers your question/doubt.


> The testing steps as follows:
> # vgs
>   VG   #PV #LV #SN Attr   VSize   VFree
>   rhel   1   1   0 wz--n- 250.00g    0 
>   vg01   1   1   0 wz--n-  10.00g    0 
> 
> # virsh pool-define-as --name vg --type logical
> Pool vg defined
> 
> # virsh pool-dumpxml vg
> <pool type='logical'>
>   <name>vg</name>
>   <uuid>2256da4d-6a6b-44e8-98e1-77b7c0211b97</uuid>
>   <capacity unit='bytes'>0</capacity>
>   <allocation unit='bytes'>0</allocation>
>   <available unit='bytes'>0</available>
>   <source>
>     <name>vg</name>
>     <format type='lvm2'/>
>   </source>
>   <target>
>     <path>/dev/vg</path>
>   </target>
> </pool>
> 
> # virsh pool-list --all |grep vg
>  vg                   inactive   no 
> 
> # virsh pool-start vg
> error: Failed to start pool vg
> error: unsupported configuration: cannot find logical volume group name 'vg'
> 
> # virsh pool-delete vg
> error: Failed to delete pool vg
> error: internal error: Child process (/usr/sbin/vgremove -f vg) unexpected
> exit status 5: 2017-05-25 11:19:19.846+0000: 5427: debug : virFileClose:110
> : Closed fd 26
> 2017-05-25 11:19:19.846+0000: 5427: debug : virFileClose:110 : Closed fd 28
> 2017-05-25 11:19:19.846+0000: 5427: debug : virFileClose:110 : Closed fd 24
>   Volume group "vg" not found
>   Cannot process volume group vg

Comment 10 jiyan 2017-06-09 06:27:46 UTC
Version-Release number of selected component:
libvirt-3.2.0-9.el7.x86_64
qemu-kvm-rhev-2.9.0-9.el7.x86_64
kernel-3.10.0-679.el7.x86_64

Step to verify:
1.About the man page, explains about the parameter are added.
For a "logical" pool only [--name] needs to be provided. The [--source-name] if provided must match the Volume Group name.If not provided, one will be generated using the [--name]. 
If provided the [--target] is ignored and a target source is generated using the [--source-name] (or as generated from the [--name]).

2.About [--source-name] and [--target]
2.1 When the [--source-name] is not provided, it is generated using [--name];and target source is generated using [--name]
# virsh pool-define-as --name pool1 --type logical
Pool pool1 defined

# virsh pool-dumpxml pool1
<pool type='logical'>
  <name>pool1</name>
  <uuid>17107290-2294-4ff5-98db-50199a7689ea</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <name>pool1</name>
    <format type='lvm2'/>
  </source>
  <target>
    <path>/dev/pool1</path>
  </target>
</pool>

2.2 When the [--source-name] is provided and match the 'Volume Group name', and target source is generated using [--source-name] 
# virsh pool-define-as --name pool2 --type logical --source-name vg01
Pool pool2 defined

# virsh pool-dumpxml pool2
<pool type='logical'>
  <name>pool2</name>
  <uuid>ce601df1-f504-43d3-beda-4f6ea6a7195c</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <name>vg01</name>
    <format type='lvm2'/>
  </source>
  <target>
    <path>/dev/vg01</path>
  </target>
</pool>

3. About [--source-host],[--source-path] and [--source-dev]
3.1 A logical pool does not process the "--source-host" and "--source-path" arguments
# virsh pool-define-as --name pool3 --type logical --source-name vg01 --source-host host1 --source-path path1
Pool pool3 defined

# virsh pool-dumpxml pool3
<pool type='logical'>
  <name>pool3</name>
  <uuid>e7a47a7d-d1b0-4b9e-bf6c-a625db50a98b</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <name>vg01</name>
    <format type='lvm2'/>
  </source>
  <target>
    <path>/dev/vg01</path>
  </target>
</pool>

3.2 The [--source-dev] is only necessary when building the pool
# virsh pool-define-as --name pool4 --type logical --source-name vg01 --source-host  - - -
Pool pool4 defined

# virsh pool-dumpxml pool4
<pool type='logical'>
  <name>pool4</name>
  <uuid>05e3159f-d99c-4054-aeb4-17c875053bf4</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <device path='-'/>
    <name>vg01</name>
    <format type='lvm2'/>
  </source>
  <target>
    <path>/dev/vg01</path>
  </target>
</pool>

# virsh pool-build pool4
error: Failed to build pool pool4
error: Storage pool probe failed: Failed to create filesystem probe for device -


4.Generate the 'default' format type for the logical pool if not provided
# virsh pool-define-as --name pool1 --type logical
Pool pool1 defined

# virsh pool-dumpxml pool1
<pool type='logical'>
  <name>pool1</name>
  <uuid>17107290-2294-4ff5-98db-50199a7689ea</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <name>pool1</name>
    <format type='lvm2'/>
  </source>
  <target>
    <path>/dev/pool1</path>
  </target>
</pool>

5.About the [--print-xml]
pool-define-as name type [--source-host hostname] [--source-path path] [--source-dev path] [--source-name name] [--target path]
       [--source-format format] [--auth-type authtype --auth-username username --secret-usage usage] [[--adapter-name name] | [--adapter-wwnn
       --adapter-wwpn] [--adapter-parent parent]] [--print-xml]
           Create, but do not start, a pool object name from the raw parameters.  If --print-xml is specified, then print the XML of the pool object
           without defining the pool.  Otherwise, the pool has the specified type.

Comment 11 errata-xmlrpc 2017-08-01 17:19:14 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://access.redhat.com/errata/RHEA-2017:1846

Comment 12 errata-xmlrpc 2017-08-01 23:59:00 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://access.redhat.com/errata/RHEA-2017:1846


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