[Kimchi-devel] Guest disk: Allocate storage volume when attaching disk to vm

[Socorro Stoppler]

Hi Aline,

I'm currently working on this feature.  I have a question below.

On 11/17/2015 05:38 AM, Aline Manera wrote:
>
>
> On 16/11/2015 15:05, Samuel Henrique De Oliveira Guimaraes wrote:
>>
>> Hi,
>>
>> I’m bit confused here. This is the current workflow:
>>
>> ·1 – CD-ROM:
>>
>> ·2 – File Path
>>
>> ·1 – Disk:
>>
>> ·2 – Storage Pool (List in Select element / Combobox)
>>
>> ·3 – Storage Volume (List in Select element / Combobox of available 
>> volumes)
>>
>> Then the new design is:
>>
>> ·1 – CD-ROM:
>>
>> ·2 – File Path
>>
>> ·1 – Disk:
>>
>> ·2 – Radio button: Create a new disk image
>>
>> ·2 – Radio button: Select existing disk image
>>
>> ·3 – Radio Button – Existing Storage Pool (List in Select element / 
>> Combobox)
>>
>> 1.4 - Storage Volume (List in Select element / Combobox of available 
>> volumes)
>>
>> ·3 – Radio Button – New Volume
>>
>> 1.4 – New Volume
>>
>> Is that right?
>>
>
> Almost there:
>
> We are proposing the following:
>
> 3. New volume
>     3.1 Select pool to create the new volume
>     3.2 Specify volume capacity
>
> In both case, new disk or existing disk, the user must select the 
> storage pool.
> For a new disk, we **don't list** iSCSI and SCSI pools (as they are 
> read-only). But from an existing disk, we can list all pools.

What storage pools will we be listing when it's a new disk?  For 
existing disk, we make the call to listStoragePools() which retrieves 
them all.
>
>> Samuel
>>
>> *From:*Aline Manera [mailto:alinefm at linux.vnet.ibm.com]
>> *Sent:* segunda-feira, 16 de novembro de 2015 14:24
>> *To:* Socorro Stoppler <socorro at linux.vnet.ibm.com>; Paulo Ricardo 
>> Paz Vital <pvital at linux.vnet.ibm.com>; Samuel Henrique De Oliveira 
>> Guimaraes <samuel.guimaraes at eldorado.org.br>; Andre Luiz Teodoro 
>> <andre.teodoro at eldorado.org.br>; Kimchi Devel <kimchi-devel at ovirt.org>
>> *Subject:* Re: Guest disk: Allocate storage volume when attaching 
>> disk to vm
>>
>>
>> Adding Samuel and Andre to this discussion and also forward to Kimchi ML.
>>
>> On 16/11/2015 14:21, Aline Manera wrote:
>>
>>
>>     Hi Socorro,
>>
>>     On 12/11/2015 21:20, Socorro Stoppler wrote:
>>
>>         Hi Aline,
>>
>>         I chatted w/Paulo about the UI portion of this.  He stated
>>         that the user has the option to select to add a new volume
>>         (in which the the UI must execute two requests: one to create
>>         a volume, and other to attach the new volume to the guest
>>         being edited).  So in this screen (I know it's the old UI but
>>         this shows better than current new UI :)):
>>
>>
>>
>>         What do you think of 3.  being radio buttons?  -
>>
>>
>>     I think 2 should be that radio buttons.
>>
>>     So:
>>
>>     1. Device type
>>         <disk>
>>
>>     2. ( ) Create a new disk image
>>
>>         ( ) Select existing disk image
>>
>>     3. Storage pool
>>         <pools>
>>
>>     4. Capacity or Volume (depends on selection on 2.)
>>
>>     Below is how virt-manage does it.
>>
>>
>>
>>
>>             <New Volume> -
>>                 Volume: Storage volume name of 'new_vol' --- we prob
>>         do not need to show this in the UI, right?
>>                 Capacity:  in bytes
>>                 Format:  qcow2 -- is this the only option we want to
>>         provide?
>>                 <Create Button>
>>
>>             <Existing Volume> - which consists of current combobox above
>>
>>         Also, if user selects to do the new volume, then created it,
>>         but decided that they didn't want to attach it, is that ok? 
>>         Not sure of the different scenarios we have
>>         or if I'm totally missing the intent here.
>>
>>         Let me know if you had envisioned something else for this UI.
>>
>>         Thanks
>>         -Socorro
>>
>

Thanks!
-Socorro

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160112/ad695995/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 50456 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160112/ad695995/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 15775 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160112/ad695995/attachment.jpe>