Hi Sheng, Unfortunately I had a missunderstanding around boot from volume, as pointed out by Robert Collins. So apologies for that. It turned out, that boot from volume is a broader concept.
Merge: Generally I would say, creating a bootable disk (Let's forget about the cloud at the moment) from a kernel, ramdisk and rootfs is not a straightforward job. I think you need a boot loader, and you need to install that bootloader to the disk, so that it will load the kernel, etc, although I am not an expert in this area. Disk image: If you download the cirros disk images, they should contain this bootloader already, this is a "disk image" https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img Tis is in qcow2 format, and could be converted to raw with the qemu-img convert command. dd ing the raw bytes to a block device should leave you with a device, which could be booted. I hope it helped, and sorry for the confusion. I think Vish described a solution to your problem here: http://lists.openstack.org/pipermail/openstack-dev/2013-July/011164.html Mate On Wed, Jul 03, 2013 at 01:52:55PM +0800, Sheng Bo Hou wrote: > Hi Mate, > > This is an issue currently I found only happens to the UEC image. > > A UEC image consists in a triplet: a kernel, an init ramdisk and a root > file system image, e.g. cirros-0.3.0-x86_64-uec, > cirros-0.3.0-x86_64-uec-kernel and cirros-0.3.0-x86_64-uec-ramdisk. If we > boot a VM from a UEC image, we need to make sure that Nova can find the > kernel_id and ramdisk_id. > > Suppose three of them have already existed in glance. I create a volume > from the root file system image(cirros-0.3.0-x86_64-uec), then only this > image is copied to a volume. If I boot a VM from the volume via "nova boot > --block-device-mapping vda=$vol_id"(no image_id specified), Nova will not > know the kernel_id and ramdisk_id, so that the VM launched in this > situation will have some issues, e.g. it can not be pinged( > https://bugs.launchpad.net/nova/+bug/1155512). I am looking for the way to > inform nova the kernel_id and ramdisk_id without a specified image_id. > > You reply gives me a new clue: is it possible to "merge" the triple images > into one via a sort of command, when creating the bootable volume from the > root file system image? Do you think qemu-img can do? I'd like to hear > from you. Thx. > > 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/02 23:34 > > To > Sheng Bo Hou/China/IBM@IBMCN, > cc > OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, > "Duncan Thomas <duncan.tho...@gmail.com> John Griffith" > <duncan.thomas@gmail.comduncan.thomas>, Avishay Traeger > <avis...@il.ibm.com>, Eric Harney <ehar...@redhat.com>, "Walter A. Boring > IV (hemna)" <walter.bor...@hp.com>, <thin...@gmail.com>, > <jsbry...@us.ibm.com> > Subject > Re: [openstack-dev] [cinder] Propose to add copying the reference images > when creating a volume > > > > > > > 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@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 > > > > > > -- > Mate Lakat > > > -- Mate Lakat _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev