Hi Daniel,
The intention of image type ('default', 'fast', ' shared',
'sharedfast') look like volume type in cinder. So I think there are two
solutions :
1. Like using volume type to configure a multiple-storage back-end in cinder,
we could extend nova API , then create image-type resource to configure a
multiple-image back-end in nova.
e.g.
in nova.conf,
libvirt_image_type=default:qcow2, fast:qcow2, shared:rbd,
sharedfast:rbd
instance_path=default:/var/nova/images/hdd,
fast:/var/nova/imges/ssd
images_rbd_pool=shared:main,sharedfast:mainssd
nova image-type-create normal_image
nova image-type-key normal_image root_disk_type=default
nova image-type-key normal_image ephemeral _disk_type=default
nova image-type-key normal_image swap_disk_type=default
nova image-type-create fast_image
nova image-type-key fast_image root_disk_type=fast
nova image-type-key fast_image ephemeral _disk_type=default
nova image-type-key fast_image swap_disk_type=fast
nova flavor-key m3.xlarge set quota:image-type= fast_image
2. Like our discussion in mails, image types are defined in configuration file,
enumerated type, ie set <libvirt_image_type> in nova.conf
e.g.
in nova.conf,
libvirt_image_type=default:qcow2, fast:qcow2, shared:rbd,
sharedfast:rbd
instance_path=default:/var/nova/images/hdd,
fast:/var/nova/imges/ssd
images_rbd_pool=shared:main,sharedfast:mainssd
nova flavor0key m3.xlarge set ephemeral_storage_type =fast
or more fine grained,
nova flavor-key m3.xlarge set quota:root_disk_type=fast
nova flavor-key m3.xlarge set quota:ephemeral_disk_type=default
nova flavor-key m3.xlarge set quota:swap_disk_type=fast
Which solution do you prefer?
If you prefer second solution, I think better to set
<libvirt_image_type> like this: libvirt_image_type=default:raw:HDD, fast:raw:SSD
*fast* means what, I think only the deployer of openstack knows clearly. So
description field would be need. "HDD" and "SSD" are the description of image
type name.
Maybe in second solution, we would not need to create/delete image-type
resource, but I think the api about listing image-types is needed. Do you think
so?
> I've already seen people asking for ability to have a choice of local image
> backends per flavor even before you raised the SSD idea.
I have seen nova blueprint list, not found any blueprint about this idea, I
will register BP and implement this idea.
Thanks.
Zhou Yu
> -----Original Message-----
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Wednesday, April 16, 2014 4:48 PM
> To: Yuzhou (C)
> Cc: openstack-dev@lists.openstack.org; Luohao (brian); Liuji (Jeremy); Bohai
> (ricky)
> Subject: Re: 【openstack-dev】【nova】discussion about add support to SSD
> ephemeral storage
>
> On Wed, Apr 16, 2014 at 02:17:13AM +0000, Yuzhou (C) wrote:
> > Hi Daniel,
> >
> > Thanks for your comments about this
> > BP：https://review.openstack.org/#/c/83727/
> >
> > My initial thoughts is to do little changes then get better
> performance of guest vm. So it is a bit too narrowly focused.
> >
> > After review SSD use case, I totally agree with your comments. I
> think if I want to implement the broader picture, there are many work items
> that need to do.
> >
> > 1. Add support to create flavor with SSD ephemeral storage.
> > The cloud adminstrator create the flavor that indicate which
> backend should be used per instance. e.g.
> > nova flavor-key m1.ssd set
> quota:ephemeral_storage_type=ssd
> > (root_disk ephemeral_disk and swap_disk are placed onto
> > a
> ssd)
> > Or more fine grained, e.g.
> > nova flavor-key m1.ssd set quota:root_disk_type=ssd
> > nova flavor-key m1.ssd set quota:ephemeral_disk_type=hd
> > nova flavor-key m1.ssd set quota:swap_disk_type=ssd
> > (root_disk and swap_disk are placed onto a ssd,
> ephemeral_disk is
> > placed onto a harddisk)
>
> I don't think you should be using the term 'ssd' here, or indeed anywhere.
> We should just be letting the admin configure multiple local image types, and
> given them each a name. Then just refer to the image types by name.
> We don't need to care whether they're SSD backed or not - just that the
> admin can configure whatever backends they want to. I've already seen
> people asking for ability to have a choice of local image backends per flavour
> even before you raised the SSD idea.
>
> > 2. When config nova,the deployer of openstack configure
> > <ephemeral_storage_pools> e.g.
> > if libvirt_image_type=default (local disk)
> > ephemeral_storage_pools=<path1>,<path2>
> > if libvirt_image_type=RBD
> > ephemeral_storage_pools=rdb1,rdb2
>
> We have to bear in mind existing config parameters:
>
> raw/qcow2 - instances_path
> lvm - images_volume_group
> rbd - images_rbd_pool
>
> I think each of those needs to be extended to allow a list of values, instead
> of a single value.
>
> Then libvirt_image_type would need to allow a list of names + types eg if we
> wanted to have 2 instances of the raw backend you could perhaps do
>
> libvirt_image_type=default:raw, fast:raw
> instances_path=default:/var/novaimages/hdd,
> fast:/var/nova/images/ssd
>
> Or if you wanted to do a choice of local qcow2 and two rbd pools, one of
> which is fast ssd backed you could do
>
> libvirt_image_type=default:qcow2, fast:qcow2, shared:rbd,
> sharedfast:rbd
> instance_path=default:/var/nova/images/hdd, fast:/var/nova/imges/ssd
> images_rbd_pool=shared:main,sharedfast:mainssd
>
> The tags 'defualt', 'fast', 'shared', 'sharedfast' would be what you'd use in
> the
> flavour to tag storage.
>
> Regards,
> Daniel
> --
> |: http://berrange.com -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org -o-
> http://virt-manager.org :|
> |: http://autobuild.org -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org -o-
> http://live.gnome.org/gtk-vnc :|
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
