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

Aline Manera alinefm at linux.vnet.ibm.com
Mon Feb 3 12:18:29 UTC 2014


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.

>
> 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

>
>    ### 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'?

>    * **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.

>
> (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?

> Regards,
>
> Rodrigo Trujillo
>
>
> _______________________________________________
> 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/bbb9111a/attachment.html>


More information about the Kimchi-devel mailing list