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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel

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