[openstack-dev] [cinder] Propose to add copying the reference images when creating a volume
mate.lakat at citrix.com
Wed Jul 3 10:16:05 UTC 2013
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.
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.
If you download the cirros disk images, they should contain this
bootloader already, this is a "disk image"
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:
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
> Sheng Bo Hou/China/IBM at IBMCN,
> 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>
> 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:
> 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
> > 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.
> > 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
> > the parameter.
> > Possible solutions: There are two ways in my mind to resolve it. One is
> > just need the code change in Nova to let it find the reference images
> > 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
> > a new way to create the bootable volume. For example, we can create
> > 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
> > > 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
> > > image during the creation of
> > > the main image. For example, an image may refer to a kernel image and
> > > 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层 邮编：
> > > _______________________________________________
> > > 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
More information about the OpenStack-dev