4:03 p.m.
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel