[RFC] Manage guest CDROM devices
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. 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. * type: The type of the storage: cdrom, disk * path *(optional)*: Path of ISO or DISK. ### Sub-resource: storage **URI:** /vms/*:name*/storage/*:name* * **GET**: Retrieve the storage information * path: Path of the storage * type: Type of the storage * **PUT**: Update storage information * name *(optional)*: The name of the storage in the VM. * path *(optional)*: Path of ISO or DISK. * **DELETE**: Remove the storage Examples: UPDATE {'path': ''} /vms/vm-1/storage/cdrom-1--> to eject the iso 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 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 ? (3) The new attached isos should be shown in the guests like changing a CD ? (4) The specification mention tuning of the devices. Should tuning be always done in the background, or allow users to specify tuning parameters ? Regards, Rodrigo Trujillo
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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
On Mon, 2014-02-03 at 04:24 -0200, 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.
Aline has suggested to use the API as "/vms/<name>/storages" : How about 'media' instead? 'storages' is not a word and sounds very strange. If we went to use storage, then, how about just 'storage?'
""" . . . 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. * type: The type of the storage: cdrom, disk * path *(optional)*: Path of ISO or DISK.
### Sub-resource: storage **URI:** /vms/*:name*/storage/*:name* * **GET**: Retrieve the storage information * path: Path of the storage * type: Type of the storage * **PUT**: Update storage information * name *(optional)*: The name of the storage in the VM. * path *(optional)*: Path of ISO or DISK. * **DELETE**: Remove the storage
Examples: UPDATE {'path': ''} /vms/vm-1/storage/cdrom-1--> to eject the iso 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 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 ? I believe so, but I think you've already researched it.
(3) The new attached isos should be shown in the guests like changing a CD ?
Yep.
(4) The specification mention tuning of the devices. Should tuning be always done in the background, or allow users to specify tuning parameters ? For new disks, etc., yes. For a CD ROM, I donno if I would worry about it.
Regards,
Rodrigo Trujillo _______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (3)
-
Aline Manera -
Christy Perez -
Rodrigo Trujillo