not a blocker candidate due to tech preview status

IMHO this command is currently supported  - however the logic behind this command is not the best match.

Reason:

The primary user request in this command is to 'convert'  existing LV into cached LV  and for this 'create' cache pool.

So this is IMHO clear sign for 'lvconvert' command.

Lvcreate command should be left here rather for creation of cached LV.
(That's the reason why I'd propose to stop supporting this command).

Ideal end result is:

lvcreate --type cache -L10 -n my_cached_volume vg

creates 'cached' 10M sized volume  'my_cached_volume' with some 'implicitly created cache pool (i.e. lvolXXX) 

compare with:

lvcreate -V10 -n thin --thinpool vg/pool

this command fails when pool does not exist.

and we need to get match for:

lvcreate --type cache --cachepool vg/existing_cache -L10 -n volume  vg.

For pool creation we use:

lvcreate --type cache-pool -L10 vg
(and we should as well handle  'lvcreate --cachepool new_pool -L10 vg)

Obviously this logic is then getting greatly confused when we start to allow to use 'lvcreate vg/lv'  for conversion.

IMHO needs more discussion - and I'm almost sure should not support this type of command

I assume we should also possibly introduce  --poolsize option.


So then we have:


lvconvert --cache --poolsize 10M  vg/origin

and even 

lvconvert --cache  vg/origin
(when we define some policy like poolsize should be i.e. 10% of origin size)


It's probably matching on thinpool support as well:

lvconvert --thin [--poolsize xxx] vg/extorigin

Converts volume into 'external' origin with thinpool with some size.
This could be seen as a 'simple way' how to use thinpool for i.e. thin snapshot creation.

For now lvconvert requires to have 'precreated' pool data volume and I think we could skip this - we have already code to detect rotational media.

As for lvcreate  -

lvcreate --cache -L10 -n cached_volume vg

It should mean to create 'origin' of 10M and the make it a cache volume and create a cache pool - again either automatically by a policy - or with --poolsize option - or by giving existing cachepool (unlike with lvconvert) --cachepool  LV.

So we then have proper logic with:

lvcreate --cache --cachepool existing_cache_pool_lv -L10 -n new_cached_volume vg

But it's getting here somewhat complicated:

with thin pools - we have '-V' for virtual thin volumes - and -L is used for pool size.

So needs discussion which logic fits best current command layout.

*** Bug 1107345 has been marked as a duplicate of this bug. ***

So as mentioned in Bug 1107345 - in commit c95d43b28c5f89e1d96f2b16805ecd74eb4b02fb it's been already recognized there is syntax parsing problem.

So we need to allow only  vg/pool with lvcreate
And with lvconvert  we use  vg/lv  to specify lv for conversion.

Current git code base of 2.02.112 supports  syntax from BZ description again,

Based on Comment 7 and Comment 8, and on the following test:

[root@tardis-02 ~]# vgcreate vg /dev/sdc1 /dev/sdd1
  Physical volume "/dev/sdc1" successfully created
  Physical volume "/dev/sdd1" successfully created
  Volume group "vg" successfully created

[root@tardis-02 ~]# lvcreate -l 50 -n normal_lv vg
  Logical volume "normal_lv" created.

[root@tardis-02 ~]# lvs -a
  LV        VG          Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  normal_lv vg          -wi-a----- 200.00m                                                    
  lv_home   vg_tardis02 -wi-ao---- 224.88g                                                    
  lv_root   vg_tardis02 -wi-ao----  50.00g                                                    
  lv_swap   vg_tardis02 -wi-ao----   4.00g                                                    

[root@tardis-02 ~]# lvcreate --type cache -n lv_cachepool -l 10 vg/normal_lv
  Logical volume vg/normal_lv is now cached.

[root@tardis-02 ~]# lvs -a
  LV                   VG          Attr       LSize   Pool           Origin            Data%  Meta%  Move Log Cpy%Sync Convert
  [lv_cachepool]       vg          Cwi---C---  40.00m                                  0.78   0.39            0.00            
  [lv_cachepool_cdata] vg          Cwi-ao----  40.00m                                                                         
  [lv_cachepool_cmeta] vg          ewi-ao----   8.00m                                                                         
  [lvol0_pmspare]      vg          ewi-------   8.00m                                                                         
  normal_lv            vg          Cwi-a-C--- 200.00m [lv_cachepool] [normal_lv_corig] 0.78   0.39            0.00            
  [normal_lv_corig]    vg          owi-aoC--- 200.00m                                                                         
  lv_home              vg_tardis02 -wi-ao---- 224.88g                                                                         
  lv_root              vg_tardis02 -wi-ao----  50.00g                                                                         
  lv_swap              vg_tardis02 -wi-ao----   4.00g                    


I will mark this BZ as VERIFIED against the original comment and bug descrption.

Verified with:

lvm2-2.02.118-2.el6.x86_64

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-1411.html