[Kimchi-devel] [RFC] Manage guest CDROM devices

[Rodrigo Trujillo]

On 02/03/2014 10:18 AM, Aline Manera wrote:
> On 02/03/2014 04:24 AM, Rodrigo Trujillo wrote:
>> Reference:
>> https://github.com/kimchi-project/kimchi/wiki/Todo-1.2
>> https://github.com/kimchi-project/kimchi/wiki/customize-VM
>>
>>
>> Royce has created the structure to add/list/lookup cdrom devices in 
>> the guests.
>> There is a patch in the list (still under revision) with the code:
>> " Kimchi-devel] [PATCH 0/5] cdrom: support add and query cdrom "
>>
>> This RFC aims to continue the second part of this work and modify the 
>> API to
>> allow user to change (UPDATE/POST) attached cd ISOs and delete 
>> (DELETE) cdrom devices.
>> If necessary I can continue the Royces work.
>>
>
> Yeap! You will need to get Royce's patches, make the adjustments 
> needed and resend the patch set.
ACK
>
>>
>> Aline has suggested to use the API as  "/vms/<name>/storages" :
>> """
>> . . .  Maybe we can use /vms/<name>/storages
>> That way we can use the same API to add/remove different kind of 
>> storages to the vm: cdrom, scsi disk, ide disk, etc ...
>> """
>> This is the first decision here
>> (1) Use  api as follow ?
>>    (I propose to use API params to differentiate the storages, like 
>> '?type=cdrom')
>>
>>    **URI:** /vms/*:name*/storages
>>    * **GET**: Retrieve all storages attached to the VM
>>    * **POST**: Attatch new storage to specified virtual machine.
>>        * name : The name of the storage in the VM.
>
> The name would be the 'dev'? like hdc, sda, etc?
>
>>        * type: The type of the storage: cdrom, disk
>
>>        * path *(optional)*: Path of ISO or DISK.
>
> Why path is optional? I think when adding a new storage to VM the user 
> must specify to where it should point
This is true for hda, sda ... what about if the user wants to add an 
empty cdrom device in the guest ?
Thats the only case I can think now, to use an empty path (virt-manager 
allows this). But, for your
facility, we can make it required, so, user can only create a cdrom dev 
if he does has a ISO to attach.
>
>>
>>    ### Sub-resource: storage
>>    **URI:** /vms/*:name*/storage/*:name*
>>    * **GET**: Retrieve the storage information
>>        * path: Path of the storage
>>        * type: Type of the storage
>
> What about 'dev'?
ACK
>
>>    * **PUT**: Update storage information
>>        * name *(optional)*: The name of the storage in the VM.
>>        * path *(optional)*: Path of ISO or DISK.
>
> We just use the notation "optional" for POST requests
>
> In this case (PUT) we just list the parameters can be updated
>
>>
>>    * **DELETE**: Remove the storage
>>
>> Examples:
>> UPDATE {'path': ''} /vms/vm-1/storage/cdrom-1--> to eject the iso
>
> No! The path to the disk should never be empty
> To eject a disk/cdrom, use DELETE request
>
>> UPDATE {'path': '/root/ubuntu.iso'} /vms/vm-1/storage/cdrom-1-->to 
>> change or insert a media
>> POST {'path':'abcd', 'bus': 'ide', 'name': 'cdrom-2'} 
>> /vms/vm-1/storage --> to attach a new cdrom
>
> 'bus'?? I didn't see any reference to it above
>
>> DELETE {} /vms/vm-1/cdroms/cdrom-1-->to detach a cdrom
>>
>> (2) Should be possible to add and remove storages with the guest 
>> running ? (Like hot plug)
>>        Does libvirt provide this ?
>
> It would be good to have. Need to check libvirt and so.
I am going to do this
>
>>
>> (3) The new attached isos should be shown in the guests like changing 
>> a CD ?
>>
>
> I didn't understand that question.
>
>> (4) The specification mention tuning of the devices. Should tuning be 
>> always done in the background, or
>> allow users to specify tuning parameters ?
>>
>
> What tuning parameters are you talking about?
Not sure, I am in doubt too. I see Virt-manager has some performance and 
tunning parameters to set, like Cache/IO mode, read/write speeds, etc

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140203/05ffa897/attachment.html>