Open Stack

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 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/02 23:34
> 
> To
> Sheng Bo Hou/China/IBM at IBMCN, 
> cc
> OpenStack Development Mailing List <openstack-dev at lists.openstack.org>, 
> "Duncan Thomas <duncan.thomas at gmail.com> John Griffith" 
> <duncan.thomas at gmail.comduncan.thomas>, Avishay Traeger 
> <avishay at il.ibm.com>, Eric Harney <eharney at redhat.com>, "Walter A. Boring 
> IV (hemna)" <walter.boring at hp.com>, <thingee at gmail.com>, 
> <jsbryant at 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 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
> 
> 
> 

-- 
Mate Lakat