Ask Your Question
0

Images may have wrong architecture

asked 2011-04-29 15:30:54 -0500

graham-hemingway gravatar image

I just used uec-publish-tarball on three images. All three images should be x86_64 but glance registers them as i386. Trying to create instances with them does not work (see https://answers.launchpad.net/nova/+question/154771 (https://answers.launchpad.net/nova/+q...) ). I get a "failed to spawn" error in nova-compute.log.

Questions:

1)Do I need to change the architecture property on these images to get them to work?

2) Is this a glance bug I should file?

Here are the details of how I published and the resulting glance details info:

root@openstack01:~/images# uec-publish-tarball maverick-server-uec-amd64.tar.gz mavImage x86_64 Fri Apr 29 09:47:21 CDT 2011: ====== extracting image ====== Warning: no ramdisk found, assuming '--ramdisk none' kernel : maverick-server-uec-amd64-vmlinuz-virtual ramdisk: none image : maverick-server-uec-amd64.img Fri Apr 29 09:47:29 CDT 2011: ====== bundle/upload kernel ====== Fri Apr 29 09:47:31 CDT 2011: ====== bundle/upload image ====== Fri Apr 29 09:48:09 CDT 2011: ====== done ====== emi="ami-00000004"; eri="none"; eki="aki-00000003"; root@openstack01:~/images# uec-publish-tarball ttylinux-uec-amd64-12.1_2.6.35-22_1.tar.gz ttyImage x86_64 Fri Apr 29 09:48:49 CDT 2011: ====== extracting image ====== kernel : ttylinux-uec-amd64-12.1_2.6.35-22_1-vmlinuz ramdisk: ttylinux-uec-amd64-12.1_2.6.35-22_1-initrd image : ttylinux-uec-amd64-12.1_2.6.35-22_1.img Fri Apr 29 09:48:50 CDT 2011: ====== bundle/upload kernel ====== Fri Apr 29 09:48:52 CDT 2011: ====== bundle/upload ramdisk ====== Fri Apr 29 09:48:53 CDT 2011: ====== bundle/upload image ====== Fri Apr 29 09:48:56 CDT 2011: ====== done ====== emi="ami-00000007"; eri="ari-00000006"; eki="aki-00000005";

root@openstack01:~/images# glance details

Found 7 public images...

URI: http://0.0.0.0/images/1 Id: 1 Public: Yes Name: None Status: active Size: 4407632 Location: file:///var/lib/glance/images/1 Disk format: aki Container format: aki Property 'image_location': u1010/maverick-server-uec-amd64-vmlinuz-virtual.manifest.xml Property 'image_state': available Property 'project_id': vhf-sandbox

Property 'architecture': i386

URI: http://0.0.0.0/images/2 Id: 2 Public: Yes Name: None Status: active Size: 1476395008 Location: file:///var/lib/glance/images/2 Disk format: ami Container format: ami Property 'kernel_id': 1 Property 'image_location': u1010/maverick-server-uec-amd64.img.manifest.xml Property 'image_state': available Property 'project_id': vhf-sandbox

Property 'architecture': i386

URI: http://0.0.0.0/images/3 Id: 3 Public: Yes Name: None Status: active Size: 4408496 Location: file:///var/lib/glance/images/3 Disk format: aki Container format: aki Property 'image_location': mavImage/maverick-server-uec-amd64-vmlinuz-virtual.manifest.xml Property 'image_state': available Property 'project_id': vhf-sandbox

Property 'architecture': i386

URI: http://0.0.0.0/images/4 Id: 4 Public: Yes Name: None Status: active Size: 1476395008 Location: file:///var/lib/glance/images/4 Disk format: ami Container format: ami Property 'kernel_id': 3 Property 'image_location': mavImage/maverick-server-uec-amd64.img.manifest.xml Property 'image_state': available Property 'project_id': vhf-sandbox

Property 'architecture': i386

URI: http://0.0.0.0/images/5 Id: 5 Public: Yes Name: None Status: active Size: 4404752 Location: file:///var/lib/glance/images/5 Disk format: aki Container format: aki Property 'image_location': ttyImage/ttylinux-uec-amd64-12.1_2.6.35-22_1-vmlinuz.manifest.xml Property 'image_state': available Property 'project_id': vhf-sandbox

Property 'architecture': i386

URI ... (more)

edit retag flag offensive close merge delete

3 answers

Sort by ยป oldest newest most voted
0

answered 2011-04-29 16:52:59 -0500

graham-hemingway gravatar image

Jay,

Thanks for the full answer. It seems that this particular flag is not really used (or it would have caused a lot of problems already). I consider this question answered. Cheers, Graham

On Apr 29, 2011, at 11:45 AM, Jay Pipes wrote:

Your question #154793 on Glance changed: https://answers.launchpad.net/glance/+question/154793 (https://answers.launchpad.net/glance/...)

Status: Open => Answered

Jay Pipes proposed the following answer: You are a wealth of questions, today, Graham :)

So, what is happening is the following series of events:

1) uec-publish-tarball is communicating with Nova's EC2 API to create an image "bundle". In this process, the EC2 API images controller communicates with Nova's S3ImageService layer. 2) The S3ImageService layer is responsible for inspecting the manifest.xml file that the uec-publish-tarball places into nova-objectstore. The information in the manifest.xml file contains things like the image machine architecture. 3) The S3ImageService adds the kernel image and the ramdisk image into Glance, and then adds the machine image to Glance. With each call to add one of these images to Glance, the S3ImageService also attaches some custom attributes (properties) to each image. One of those custom attributes is the "architecture". When you do glance index or glance show <id>, these custom attributes appear as "Property 'key': value", as you've shown above.

So, Glance actually just stores whatever Nova's S3ImageService tells it to :) At this time, there's no magic inspection that Glance does to find the architecture... it's pretty dumb and just accepts whatever the caller of glance add supplies.

In summary, the reason the architecture is showing as i386 is because that is what is being written to the manifest.xml. euca-bundle-image (and uec-publish-tarball) use the eucatools euca.generate_manifest() method to do this, and neither Nova nor Glance have any ability to change this.

Hmm, that was a really long way of saying unfortunately neither Glance nor Nova can fix this issue... I hope the explanation makes things a bit clearer. I totally understand the process of image management is overly complex and obtuse. It's just that there are certain aspects of that process that we don't have any control over :(

Cheers! jay


If this answers your question, please go to the following page to let us know that it is solved: https://answers.launchpad.net/glance/+question/154793/+confirm?answer_id=0 (https://answers.launchpad.net/glance/...)

If you still need help, you can reply to this email or go to the following page to enter your feedback: https://answers.launchpad.net/glance/+question/154793 (https://answers.launchpad.net/glance/...)

You received this question notification because you are a direct subscriber of the question.

Graham Hemingway mobile: (615) 294-7133 chat/email: graham.hemingway@gmail.com

edit flag offensive delete link more
0

answered 2011-04-29 16:45:43 -0500

jaypipes gravatar image

You are a wealth of questions, today, Graham :)

So, what is happening is the following series of events:

1) uec-publish-tarball is communicating with Nova's EC2 API to create an image "bundle". In this process, the EC2 API images controller communicates with Nova's S3ImageService layer. 2) The S3ImageService layer is responsible for inspecting the manifest.xml file that the uec-publish-tarball places into nova-objectstore. The information in the manifest.xml file contains things like the image machine architecture. 3) The S3ImageService adds the kernel image and the ramdisk image into Glance, and then adds the machine image to Glance. With each call to add one of these images to Glance, the S3ImageService also attaches some custom attributes (properties) to each image. One of those custom attributes is the "architecture". When you do glance index or glance show <id>, these custom attributes appear as "Property 'key': value", as you've shown above.

So, Glance actually just stores whatever Nova's S3ImageService tells it to :) At this time, there's no magic inspection that Glance does to find the architecture... it's pretty dumb and just accepts whatever the caller of glance add supplies.

In summary, the reason the architecture is showing as i386 is because that is what is being written to the manifest.xml. euca-bundle-image (and uec-publish-tarball) use the eucatools euca.generate_manifest() method to do this, and neither Nova nor Glance have any ability to change this.

Hmm, that was a really long way of saying unfortunately neither Glance nor Nova can fix this issue... I hope the explanation makes things a bit clearer. I totally understand the process of image management is overly complex and obtuse. It's just that there are certain aspects of that process that we don't have any control over :(

Cheers! jay

edit flag offensive delete link more
0

answered 2011-04-29 18:47:54 -0500

jaypipes gravatar image

Considered answered...

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2011-04-29 15:30:54 -0500

Seen: 100 times

Last updated: Apr 29 '11