On Jul 1, 2013, at 3:35 AM, Sheng Bo Hou <sb...@cn.ibm.com> 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). >
You should be able to create an image in glance that references the volume in block device mapping but also has a kernel_id and ramdisk_id parameter so it can boot properly. I know this is kind of an odd way to do things, but this seems like an edge case and I think it is a valid workaround. Vish > 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@IBMCN E-mail: sb...@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.la...@citrix.com> > 2013/07/01 04:18 > Please respond to > OpenStack Development Mailing List <openstack-dev@lists.openstack.org> > > To > OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, > cc > jsbry...@us.ibm.com, "Duncan Thomas <duncan.tho...@gmail.com> John Griffith" > <duncan.thomas@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@IBMCN E-mail: sb...@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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > Mate Lakat > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev