Bug 1398087

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.

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

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
$

A revert of mentioned changes has been proposed upstream:
https://www.redhat.com/archives/libvir-list/2017-March/msg01416.html

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

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

(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

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.

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

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