Re: [openstack-dev] [cinder] Propose to add copying the reference images when creating a volume
Hi Vish, I would like you to review this patch https://review.openstack.org/#/c/35460/. I think this approach takes the least effort to fix this issue. When we boot an instance from a volume, nova can get the volume information by _get_volume. kerel_id and ramdisk_id are already in the volume information. We just need to make nova retrieve them. In the code of creating instance, kernel_id and ramdisk_id are accessed by checking properties(many parts), but the volume information saved them in volume_image_metadata. I just convert the data structure a bit and save two of this params in properties, and it can work. Well, if you do not see it favorable, we can work it out in another way. Thank you. 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@IBMCNE-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 Vishvananda Ishaya vishvana...@gmail.com 2013/07/02 01:14 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 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@IBMCNE-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
Re: [openstack-dev] [cinder] Propose to add copying the reference images when creating a volume
On Mon, Jul 1, 2013 at 11:14 AM, Vishvananda Ishaya vishvana...@gmail.comwrote: 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@IBMCNE-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
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@IBMCNE-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
Re: [openstack-dev] [cinder] Propose to add copying the reference images when creating a volume
On 1 July 2013 20:18, Mate Lakat mate.la...@citrix.com wrote: 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. This doesn't make any sense to me. Where you boot from, and what your root filesystem are are orthogonal issues. boot from volume shouldn't alter that. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Propose to add copying the reference images when creating a volume
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@IBMCNE-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
[openstack-dev] [cinder] Propose to add copying the reference images when creating a volume
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@IBMCNE-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
