Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1569000 - Logical size of the devices should be 10 times of the physical size
Summary: Logical size of the devices should be 10 times of the physical size
Alias: None
Product: cockpit-ovirt
Classification: oVirt
Component: Gdeploy
Version: 0.11.7
Hardware: x86_64
OS: Linux
Target Milestone: ovirt-4.4.0
: ---
Assignee: Gobinda Das
Depends On:
Blocks: 1568997
TreeView+ depends on / blocked
Reported: 2018-04-18 13:37 UTC by bipin
Modified: 2019-11-20 08:50 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1568997
Last Closed: 2019-11-20 08:50:03 UTC
oVirt Team: Gluster
sabose: ovirt-4.3?
bshetty: planning_ack?
bshetty: devel_ack?
bshetty: testing_ack?

Attachments (Terms of Use)

Description bipin 2018-04-18 13:37:46 UTC
+++ This bug was initially created as a clone of Bug #1568997 +++

Description of problem:
Currently the Logical size for VDO is 10 times the sum of all bricks created. But the logical size should always be 10 times of the physical size of device.
If the device /dev/sdb has a size of the of 20T. Then the logical size should be 200T. This should be irrespective of the brick size selected for each volume.

Also considering a scenario where, if the device size is 20 TB and a volume created out of it is 1T then the logical size will be 10T. Which is less than the physical size. (physical size 20TB > logical size 10 T). This is not recommended according to VDO. 
This also eliminates the work of adding the logical size every time we create a new volume.

NOTE: Also had previously confirmed the same with Dennis Keefe. Please find the comment below:

    2. vdoLogicalSize = 10 x ( Disk physical size )
    In actual, the cockpit implementation does 4 x size of physical disk.
    I read from the RHEL 7.5 storage admin guide, about the recommendation of 10:1

 The cockpit implementation will allow much large size, though you have to manually change the settings.
10x is typical for VMs.  I agree with this setting.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Login to cockpit UI
2. Start gluster deployment 
3. Select the  enable compression and dedupe check

Actual results:

Expected results:

Additional info:

Comment 1 Sahina Bose 2018-04-23 07:27:36 UTC
Can the VDO volume be resized post creation?

Comment 2 Sahina Bose 2018-04-23 07:34:52 UTC
I do see that vdo supports increasing logical volume size and physical volume size as per https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/vdo-ig-administering-vdo 

Bipin, can you try this out?

Comment 3 bipin 2018-04-23 07:40:17 UTC

The logical size expansion is working. Lowering the severity.

Comment 4 Sandro Bonazzola 2019-01-28 09:41:22 UTC
This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

Comment 5 Sahina Bose 2019-01-30 11:51:19 UTC
Gobinda, do we plan to address this?

Comment 6 Gobinda Das 2019-02-18 07:40:45 UTC
Now the problem is to get device details from remote hosts in cockpit. Will need to try and find a way to get device details of other nodes.Then only will be able to fix this. I tried sometimes back using ansible playbook, but did not work. Will try again. I think we should move this to 4.4 as the logical size is editable and user can give exact value during deployment.

Comment 7 Gobinda Das 2019-11-20 08:50:03 UTC
As same device may use to create bricks we can't really determine what is the actual size of device. Cockpit will be accessing from one host and we need to get other hosts device info as well which is not possible from cockpit. So closing this bug.

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