lvm2 code added esitamation for memory requirements needed by running VDO target. This function however incorrectly estimates the size when VDO volume is resized and could even potentially leave device in suspended state since the calculation were provided also during already suspended state. Also provided guiding messages were misleading user about required memory. Bug is present in released upstream version 2.03.18 and is fixed with these commits (in upstream 2.03.19): https://listman.redhat.com/archives/lvm-devel/2023-January/024531.html https://listman.redhat.com/archives/lvm-devel/2023-January/024532.html https://listman.redhat.com/archives/lvm-devel/2023-January/024533.html https://listman.redhat.com/archives/lvm-devel/2023-January/024534.html https://listman.redhat.com/archives/lvm-devel/2023-January/024534.html To test correct behavior - Find some largest support virtual size VDO LV for VDO-Pool LV on given hardware - i.e. for 4GiB RAM system check if i.e. 1.5PiB VDO LV can be created. Remove such VDO LV, and create new one with 1PiB virtual VDO volume size and try to extend this virtual VDO volume by i.e. 500TiB - with fixed version this should work - previously lvm2 command has failed. This bug is mainly show when exercising very large sizes of virtual VDO volumes and was not noticed within ~TiB range volume sizes used in common testing. Also patches now correctly handles input sizes about allowed range where lvm2 errored command with incorrect/misleading error message (i.e. check 'lvcreate -L4P)