[RFC]Create VM from image
Currently kimchi just support create a vm from an ISO defined template. This requires duplicate installation. This release we want to support create a vm from an installed image. This involves the following change: 1. Create a template from an image: POST /templates/template-1 {'base': 'abs_base_img_path'} Implementation: (1)probe image os distro and version to get suggested config. (2)Avoid image to be deleted. (3)Avoid using ISO and base image at the same time. 2. Create a vm from image based template: This part has already been covered by Aline's prototype patch. POST /vms/vm-1 {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path'}]} or {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path', 'volume': 'scsi_volume'}]} The create vm implementation need to be re-considered for the following points: (1) when creating vm on scsi/iscsi pool, if volume size smaller than original image, need to be rejected. (2) when creating vm on directory based pool, volume generating logic is different with allocation new volume. (2) xml generating need to be refactored. Anything else need to be considered, welcome your comments.
On Tue, 2014-07-01 at 15:53 +0800, Royce Lv wrote:
Currently kimchi just support create a vm from an ISO defined template. This requires duplicate installation. This release we want to support create a vm from an installed image.
This involves the following change:
1. Create a template from an image:
POST /templates/template-1 {'base': 'abs_base_img_path'}
Implementation: (1)probe image os distro and version to get suggested config. (2)Avoid image to be deleted. (3)Avoid using ISO and base image at the same time.
2. Create a vm from image based template: This part has already been covered by Aline's prototype patch.
POST /vms/vm-1 {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path'}]} or {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path', 'volume': 'scsi_volume'}]}
The create vm implementation need to be re-considered for the following points: (1) when creating vm on scsi/iscsi pool, if volume size smaller than original image, need to be rejected. (2) when creating vm on directory based pool, volume generating logic is different with allocation new volume. (2) xml generating need to be refactored.
Anything else need to be considered, welcome your comments.
this might be something for down the line, but some distros (not sure which, other than Ubuntu) or even private organizations, keep image files online too. So we might want to think about allowing remote images to be used. This would have to be different than the remote template logic, of course, since we would want to pull the image down into a storage pool and then use it locally. Scroll to the bottom: http://cloud-images.ubuntu.com/precise/current/ http://cloud-images.ubuntu.com/
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Regards, - Christy
On 2014年07月02日 04:07, Christy Perez wrote:
On Tue, 2014-07-01 at 15:53 +0800, Royce Lv wrote:
Currently kimchi just support create a vm from an ISO defined template. This requires duplicate installation. This release we want to support create a vm from an installed image.
This involves the following change:
1. Create a template from an image:
POST /templates/template-1 {'base': 'abs_base_img_path'}
Implementation: (1)probe image os distro and version to get suggested config. (2)Avoid image to be deleted. (3)Avoid using ISO and base image at the same time.
2. Create a vm from image based template: This part has already been covered by Aline's prototype patch.
POST /vms/vm-1 {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path'}]} or {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path', 'volume': 'scsi_volume'}]}
The create vm implementation need to be re-considered for the following points: (1) when creating vm on scsi/iscsi pool, if volume size smaller than original image, need to be rejected. (2) when creating vm on directory based pool, volume generating logic is different with allocation new volume. (2) xml generating need to be refactored.
Anything else need to be considered, welcome your comments.
this might be something for down the line, but some distros (not sure which, other than Ubuntu) or even private organizations, keep image files online too. So we might want to think about allowing remote images to be used. This would have to be different than the remote template logic, of course, since we would want to pull the image down into a storage pool and then use it locally.
Scroll to the bottom: http://cloud-images.ubuntu.com/precise/current/ http://cloud-images.ubuntu.com/
Thanks Christy! That is exactly what I want for this feature.Together with what I posted in RFC "Upload and download image for OOTB storage pool". The whole flow of this scenario will be: 1. download a cloud image to ISO storage pool. 2. create a template from this cloud image. 3. create a vm from this template. I agree with you that this is different from the remote template logic, because this image is the base image of other vms. And other vms' image file is cow image of this base. If this base image locates remotely, I'm afraid this will be an IO bottleneck of the VM. This is different with ISO streaming, because ISO is only used one time when installation, but this base image file will be used every time read occurs.
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Regards,
- Christy
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 2014年07月02日 04:07, Christy Perez wrote:
On Tue, 2014-07-01 at 15:53 +0800, Royce Lv wrote:
Currently kimchi just support create a vm from an ISO defined template. This requires duplicate installation. This release we want to support create a vm from an installed image.
This involves the following change:
1. Create a template from an image:
POST /templates/template-1 {'base': 'abs_base_img_path'}
Implementation: (1)probe image os distro and version to get suggested config. (2)Avoid image to be deleted. (3)Avoid using ISO and base image at the same time.
2. Create a vm from image based template: This part has already been covered by Aline's prototype patch.
POST /vms/vm-1 {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path'}]} or {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path', 'volume': 'scsi_volume'}]}
The create vm implementation need to be re-considered for the following points: (1) when creating vm on scsi/iscsi pool, if volume size smaller than original image, need to be rejected. (2) when creating vm on directory based pool, volume generating logic is different with allocation new volume. (2) xml generating need to be refactored.
Anything else need to be considered, welcome your comments.
this might be something for down the line, but some distros (not sure which, other than Ubuntu) or even private organizations, keep image files online too. So we might want to think about allowing remote images to be used. This would have to be different than the remote template logic, of course, since we would want to pull the image down into a storage pool and then use it locally.
Scroll to the bottom: http://cloud-images.ubuntu.com/precise/current/ http://cloud-images.ubuntu.com/
Thanks Christy!
That is exactly what I want for this feature.Together with what I posted in RFC "Upload and download image for OOTB storage pool". The whole flow of this scenario will be: 1. download a cloud image to ISO storage pool. 2. create a template from this cloud image. 3. create a vm from this template. I think I may have misunderstood the OOTB storage pool a bit then. I'll have to re-read those e-mails more carefully.
I agree with you that this is different from the remote template logic, because this image is the base image of other vms. And other vms' image file is cow image of this base. If this base image locates remotely, I'm afraid this will be an IO bottleneck of the VM. This is different with ISO streaming, because ISO is only used one time when installation, but this base image file will be used every time read occurs. I was thinking we'd pull it down and use the local one going forward, after making a template from it. Re-reading what I wrote, I didn't make
On Wed, 2014-07-02 at 10:40 +0800, Royce Lv wrote: that very clear.
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Regards,
- Christy
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 07/01/2014 04:53 AM, Royce Lv wrote:
Currently kimchi just support create a vm from an ISO defined template. This requires duplicate installation. This release we want to support create a vm from an installed image.
This involves the following change:
1. Create a template from an image:
POST /templates/template-1 {'base': 'abs_base_img_path'}
Implementation: (1)probe image os distro and version to get suggested config. (2)Avoid image to be deleted. (3)Avoid using ISO and base image at the same time.
2. Create a vm from image based template: This part has already been covered by Aline's prototype patch.
POST /vms/vm-1 {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path'}]} or {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path', 'volume': 'scsi_volume'}]}
The create vm implementation need to be re-considered for the following points: (1) when creating vm on scsi/iscsi pool, if volume size smaller than original image, need to be rejected.
From that, I assume you will copy the img content to the scsi/iscsi volume. Is that correct? If so, can't we use backing store (http://libvirt.org/formatstorage.html#StorageVolBacking) for the existing img and make the vm volume the RW img? During my prototype development, I used backing store and it worked well with directory storage volumes But I haven't tested it with scsi/iscsi volumes
(2) when creating vm on directory based pool, volume generating logic is different with allocation new volume. (2) xml generating need to be refactored.
Anything else need to be considered, welcome your comments.
On 2014年07月02日 11:23, Aline Manera wrote:
On 07/01/2014 04:53 AM, Royce Lv wrote:
Currently kimchi just support create a vm from an ISO defined template. This requires duplicate installation. This release we want to support create a vm from an installed image.
This involves the following change:
1. Create a template from an image:
POST /templates/template-1 {'base': 'abs_base_img_path'}
Implementation: (1)probe image os distro and version to get suggested config. (2)Avoid image to be deleted. (3)Avoid using ISO and base image at the same time.
2. Create a vm from image based template: This part has already been covered by Aline's prototype patch.
POST /vms/vm-1 {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path'}]} or {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path', 'volume': 'scsi_volume'}]}
The create vm implementation need to be re-considered for the following points: (1) when creating vm on scsi/iscsi pool, if volume size smaller than original image, need to be rejected.
From that, I assume you will copy the img content to the scsi/iscsi volume. Is that correct? If so, can't we use backing store (http://libvirt.org/formatstorage.html#StorageVolBacking) for the existing img and make the vm volume the RW img?
During my prototype development, I used backing store and it worked well with directory storage volumes But I haven't tested it with scsi/iscsi volumes
Yes, we will use the backing file, but since the original image may be a small image with a large size, the rest most part will be write to the SCSI/iSCSI volume, to *guarantee* volume will not explode in write, the cow volume needs to be >= declared. It is a secure choice, but yes, there will be some waste in space.
(2) when creating vm on directory based pool, volume generating logic is different with allocation new volume. (2) xml generating need to be refactored.
Anything else need to be considered, welcome your comments.
On 07/02/2014 11:23 AM, Aline Manera wrote:
On 07/01/2014 04:53 AM, Royce Lv wrote:
Currently kimchi just support create a vm from an ISO defined template. This requires duplicate installation. This release we want to support create a vm from an installed image.
This involves the following change:
1. Create a template from an image:
POST /templates/template-1 {'base': 'abs_base_img_path'}
Implementation: (1)probe image os distro and version to get suggested config. (2)Avoid image to be deleted. (3)Avoid using ISO and base image at the same time.
2. Create a vm from image based template: This part has already been covered by Aline's prototype patch.
POST /vms/vm-1 {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path'}]} or {'storagepool': 'default', 'network': 'default', 'disks':[{'index':0, 'base': 'abs_path', 'volume': 'scsi_volume'}]}
The create vm implementation need to be re-considered for the following points: (1) when creating vm on scsi/iscsi pool, if volume size smaller than original image, need to be rejected.
From that, I assume you will copy the img content to the scsi/iscsi volume. Is that correct? If so, can't we use backing store (http://libvirt.org/formatstorage.html#StorageVolBacking) for the existing img and make the vm volume the RW img?
We should let user to check backing store on not. If user want high performance, then he will give up backing store. the volume can be any valid volume. raw/qcow file, logical disk or scsi/iscsi.
During my prototype development, I used backing store and it worked well with directory storage volumes But I haven't tested it with scsi/iscsi volumes
(2) when creating vm on directory based pool, volume generating logic is different with allocation new volume. (2) xml generating need to be refactored.
Anything else need to be considered, welcome your comments.
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
participants (4)
-
Aline Manera -
Christy Perez -
Royce Lv -
Sheldon