12:24 a.m.
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
6:18 a.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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
7:26 a.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
3949
days inactive
3950
days old
3 comments
3 participants
participants (3)
-
Aline Manera -
Christy Perez -
Rodrigo Trujillo