Open Stack

Hi Sheng,

You can use a raw(qemu-img recognised) type image to glance, and ask
cinder to create a volume from that. This way you end up with a bootable
volume. In the end of the day, your instance will just see a block
device. The default cinder driver should also recognise other formats
that are understood by qemu-img.

As an advertisement, I just added a patch to make it able to recognise
XenServer type images:

https://review.openstack.org/34336

Mate

On Mon, Jul 01, 2013 at 06:35:03AM -0400, Sheng Bo Hou wrote:
> Hi Mate,
> 
> First, thanks for answering.
> I was trying to find the way to prepare the bootable volume.
> Take the default image downloaded by devstack, there are three images: 
> cirros-0.3.0-x86_64-uec, cirros-0.3.0-x86_64-uec-kernel and 
> cirros-0.3.0-x86_64-uec-ramdisk.
> cirros-0.3.0-x86_64-uec-kernel is referred as the kernel image and 
> cirros-0.3.0-x86_64-uec-ramdisk is referred as the ramdisk image.
> 
> Issue: If only the image(cirros-0.3.0-x86_64-uec) is copied to the volume 
> when creating a volume) from an image, this volume is unable to boot an 
> instance without the references to the kernel and the ramdisk images. The 
> current cinder only copies the image cirros-0.3.0-x86_64-uec to one 
> targeted volume(Vol-1), which is marked as bootable but unable to do a 
> successful boot with the current nova code, even if image-id is removed in 
> the parameter.
> 
> Possible solutions: There are two ways in my mind to resolve it. One is we 
> just need the code change in Nova to let it find the reference images for 
> the bootable volume(Vol-1) and there is no need to change anything in 
> cinder, since the kernel and ramdisk id are saved in the 
> volume_glance_metadata, where the references point to the images(kernel 
> and ramdisk) for the volume(Vol-1). 
> 
> The other is that if we need multiple images to boot an instance, we need 
> a new way to create the bootable volume. For example, we can create three 
> separate volumes for three of the images and set the new references in 
> volume_glance_metadata with the kernel_volume_id and ramdisk_volume_id. 
> The benefit of this approach is that the volume can live independent of 
> the existence of the original images. Even the images get lost 
> accidentally, the volumes are still sufficient to boot an instance, 
> because all the information have been copied to Cinder part.
> 
> I am trying to looking for the "another way to prepare your bootable 
> volume" as you mentioned and asking for the suggestions. 
> And I think the second approach could be one way. Do you think it is a 
> good approach?
> 
> Best wishes,
> Vincent Hou (侯胜博)
> 
> Staff Software Engineer, Open Standards and Open Source Team, Emerging 
> Technology Institute, IBM China Software Development Lab
> 
> Tel: 86-10-82450778 Fax: 86-10-82453660
> Notes ID: Sheng Bo Hou/China/IBM at IBMCN    E-mail: sbhou at cn.ibm.com 
> Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang 
> West Road, Haidian District, Beijing, P.R.C.100193
> 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193
> 
> 
> 
> Mate Lakat <mate.lakat at citrix.com> 
> 2013/07/01 04:18
> Please respond to
> OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
> 
> 
> To
> OpenStack Development Mailing List <openstack-dev at lists.openstack.org>, 
> cc
> jsbryant at us.ibm.com, "Duncan Thomas <duncan.thomas at gmail.com> John 
> Griffith" <duncan.thomas at gmail.comduncan.thomas>
> Subject
> Re: [openstack-dev] [cinder] Propose to add copying the reference images 
> when creating a volume
> 
> 
> 
> 
> 
> 
> Hi,
> 
> I just proposed a patch for the boot_from_volume_exercise.sh to get rid
> of --image. To be honest, I did not look at the various execution paths.
> My initial thought is that boot from volume means you boot from volume.
> If you only have a kernel + ramdisk image, I simply assumed that you
> can't do it. 
> 
> I would not do any magic. Boot from volume should boot from volume. If
> you only have 3 part images, you need to find another way to prepare
> your bootable volume.
> 
> btw, here is my change:
> 
> https://review.openstack.org/34761
> 
> Cheers,
> Mate
> 
> On Mon, Jul 01, 2013 at 01:25:23AM -0400, Sheng Bo Hou wrote:
> > Hi Cinder folks,
> > 
> > I am currently fixing the bugs related to booting the instance from the 
> > volume. I found there are bugs both in Nova and 
> > Cinder.
> > 
> > Cinder: https://bugs.launchpad.net/cinder/+bug/1159824
> > Nova: https://bugs.launchpad.net/nova/+bug/1191069
> > 
> > For the volumes created from the image, I propose to copy the reference 
> > image during the creation of
> > the main image. For example, an image may refer to a kernel image and a 
> > ramdisk image. When we create a volume
> > from this image, we only copied this one to the volume. The kernel and 
> > ramdisk images are still in glance, and
> > the volume still refers to the kernel and ramdisk images.
> > 
> > I think if an image has other reference images, the reference images 
> also 
> > need to be copied to the volumes(kernel volume and ramdisk volume),
> > and then set the volume referring to the kernel volume and the ramdisk 
> > volume. This feature will make booting from
> > a volume completely independent of the existence of the glance image.
> > 
> > Do you think we can firstly add this feature to cinder? Do folks have 
> any 
> > comments on it?
> > 
> > Thanks.
> > 
> > Best wishes,
> > Vincent Hou (侯胜博)
> > 
> > Staff Software Engineer, Open Standards and Open Source Team, Emerging 
> > Technology Institute, IBM China Software Development Lab
> > 
> > Tel: 86-10-82450778 Fax: 86-10-82453660
> > Notes ID: Sheng Bo Hou/China/IBM at IBMCN    E-mail: sbhou at cn.ibm.com 
> > Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang 
> > West Road, Haidian District, Beijing, P.R.C.100193
> > 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193
> 
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> -- 
> Mate Lakat
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 

-- 
Mate Lakat