[Kimchi-devel] [RFC] Create logical pool from existing VG

Aline Manera alinefm at linux.vnet.ibm.com
Thu Oct 15 18:58:24 UTC 2015



On 15/10/2015 14:00, Jose Ricardo Ziviani wrote:
>
>
> On 15-10-2015 13:12, Aline Manera wrote:
>>
>>
>> On 15/10/2015 12:00, Jose Ricardo Ziviani wrote:
>>>
>>>
>>> On 15-10-2015 11:56, Aline Manera wrote:
>>>>
>>>>
>>>> On 15/10/2015 11:45, Jose Ricardo Ziviani wrote:
>>>>> Hello,
>>>>>
>>>>> I'm about to write a new feature to Kimchi. It will allow users to
>>>>> define any existing volume group as a storage pool, where guests will
>>>>> be able to create logical volumes into it. NOTE: VGs already in 
>>>>> use as
>>>>> storage pool won't be listed.
>>>>>
>>>>> I read Pooja's "[RFC] Proposal to manage Physical Volumes on Ginger",
>>>>> and now I think all LVM code should be implemented in WOK so both
>>>>> plugins (Kimchi/Ginger) could take advantages from that.
>>>>>
>>>>> API:
>>>>>
>>>>> Collection: /plugins/kimchi/host/vgs
>>>>> Method: GET
>>>>> Returns: list of vgnames:
>>>>> [vgname1, vgname2]
>>>>>
>>>>
>>>> ACK
>>>>
>>>>> Resource: /plugins/kimchi/host/vg/vgname
>>>>> Method: GET
>>>>> Returns: dict
>>>>> { vgname, size, free_size, [PV partition list, like: sda4, sdb3], [LV
>>>>> name list, like: lv_root] }
>>>>>
>>>>
>>>> ACK
>>>>
>>>>> Resource: /plugins/kimchi/storagepools/vgname
>>>>> Method: POST
>>>>> data: { vgname, storagepool_name, type=logical }
>>>>
>>>> I am little bit confused with this API. Usually the POST is done in a
>>>> Collection so, something like:
>>>>
>>>> POST /plugins/kimchi/storagepools {name: pool_name, type: logical,
>>>> vgname: vg_name}
>>>>
>>>> Is that what you are proposing?
>>>
>>> yes! updating:
>>>
>>> Collection: /plugins/kimchi/storagepools
>>> Method: POST
>>> data: {name: pool_name, type: logical, vgname: vg_name}
>>>
>>>>
>>>>>
>>>>> The frontend, I think we could have a table indicating all available
>>>>> devices available for a logical storage pool, for example:
>>>>>
>>>>>
>>>>> Define a New Storage Pool
>>>>> 1. Storage Pool Name
>>>>> +-----------------------------------------+
>>>>> | mypool                                  |
>>>>> +-----------------------------------------+
>>>>> The name used to identify the storage pools, and it should not be
>>>>> empty.
>>>>>
>>>>> 2. Storage Pool Type
>>>>> +-----------+
>>>>> | LOGICAL   |
>>>>> +-----------+
>>>>>
>>>>> 3. Device path
>>>>> +-------+-------+---------------+---------------+
>>>>> |       |device | size        | free size    |
>>>>> +-------+-------+---------------+---------------+
>>>>> | ()     | sdb    | 50 GiB    | 50 GiB    |
>>>>> +-------+-------+---------------+---------------+
>>>>> | ()     | sdc    | 10 GiB    | 8 GiB        |
>>>>> +-------+-------+---------------+---------------+
>>>>> | ()    | vg_a    | 20 GiB    | 18 GiB    |
>>>>> +-------+-------+---------------+---------------+
>>>>>
>>>>> +--------+
>>>>> | Create |
>>>>> +--------+
>>>>
>>>> May user select multiple VGs to create a logical pool? Or is it 
>>>> restrict
>>>> to one by one, one VG, one logical pool?
>>>> Depending on that, we need to redesign the UI
>>>
>>> Nope, my initial idea is to have 1 device to 1 storage pool. That's is
>>> because users can group many partitions (PVs) into one VG.
>>
>> So I suggest to have separated options: one to create a logical pool
>> from raw disks and other one to create a logical pool from an 
>> existing VG.
>
>
> I see, so we will have:
>
> 2. Storage Pool Type
> +--------------------------+
> | (snip)
> | LOGICAL                  |
> | LOGICAL FROM EXISTING VG |
> | (snip)                   |
> +--------------------------+
>

Or keep only one Logical entry here and a radio box to switch between VG 
or raw disks.

( ) Create from existing LVM                  ( ) Create from raw disks

Once one of those options is selected more options are displayed below, 
in a similar way you did.

> and, suppose 'LOGICAL FROM EXISTING VG' is selected
>
> +-------+---------------+---------------+---------------+
> |    | device    | size        | free size    |
> +-------+---------------+---------------+---------------+
> |  ()   | vg_a          | 20 GiB    | 18 GiB    |
> |  ()   | vg_b        | 10 GiB    | 5 GiB        |
> +-------+---------------+---------------+---------------+
>
> Any other pool type will keep unchanged.


>
> Note: I intend to not list VGs without free space available. What do 
> you think?

Agree.

>>
>>>
>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Kimchi-devel mailing list
>>>>> Kimchi-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>>
>>>>
>>>
>>
>




More information about the Kimchi-devel mailing list