Resizing LVM-VDO: set physical and virtual sizes independently

[hostalp]

When creating a LVM-VDO volume it's possible to specify the physical and virtual (logical) volume sizes: lvcreate --type vdo --size 1T --virtualsize 5T ...
When increasing such volume size, it appears that only the physical volume size can be specified while the virtual size is adjusted automatically using the current virtual:physical sizes ratio. The lvextend and lvresize commands simply don't appear to accept the --virtualsize argument.

So what if one wants to increase both sizes independently - e.g. to achieve a different virtual:physical sizes ratio (to match the reality more closely because the situation has changed since the volume was created)? Is it possible somehow (directly)?

[zkabelac]

Yes - we have already some plans to add support for --virtualsize - that would alllow these operations.

Meanwhile you will need to use standard mechanism to scale 'VdopoolLV' separately from VdoLV - so you need to run 2 'lvextend' commands with -L.

It's wort to be noted there is no 'stong' connection between ratio of virtual and physical size - so you shouldn't worry that much the operation will run independently - in fact you should probably leave resizing of physical size on 'dmeventd' automated threshold based resize - so the physical space is consumed when really needed.

And last note - once the 'physical' size is extended - we do not support shrinking - unlike for virtual size.... - so it's always better to delay physical extension as this cannot be (ATM) reduced...

[hostalp]

run 2 'lvextend' commands with -L

Yes, thanks for the hint, I forgot about the possibility to deal with those LVs separately. That did it for now.

By the way, I'm not sure whether it's expected behavior, but when I tried executing lvextend with --type vdo-pool on the VDO pool LV (the one for which lvs -o name,size,segtype,lv_layout,lv_attr outputs Type: vdo-pool, Layout: vdo,pool, Attr: dwi-------), it failed with VolumeType does not match (vdo-pool). Omitting the --type argument got it to work.

[zkabelac]

Well - yeah there are some technical details behind the scene - i.e. here you want to 'physically' extend 'dataLV' for vdopool - so to allocate physically space from VG (same as with thinpool the extending type need to match the type of DataLV....

So it's rather syntax sugar lvm passes the resize to from VdoPoolLV -> VdoDataLV.

When user is using option --type - it's rather very low-level option allowing detailed control over what lvm2 is allowed to do.
The less options are given to the command the better chance is lvm2 can do something smart - (or dumb depends on POV :) )