Join us at engage.eucalyptus.com
Well, after three days I still can't boot an image with Eucalyptus.
Following the directions here:
http://open.eucalyptus.com/wiki/EucalyptusImageManagement_v2.0
Using the CentOS 5 64bit small image from this page:
http://open.eucalyptus.com/wiki/starter-emis
While we're on that subject, why are there two wiki pages with the same info?
Here: http://open.eucalyptus.com/wiki/starter-emis, and
here: http://open.eucalyptus.com/wiki/EucalyptusArchivedCertifiedImages
What's the difference between "Archived Certified EMIs" and "Starter Eucalyptus Machine Images (EMIs)" apart from being downright confusing?
I'm running these commands:
euca-bundle-image -i vmlinuz-2.6.27.21-0.1-xen --kernel true
euca-upload-bundle -b kernel_bucket -m /tmp/vmlinuz-2.6.27.21-0.1-xen.manifest.xml
euca-register kernel_bucket/vmlinuz-2.6.27.21-0.1-xen.manifest.xml
euca-bundle-image -i euca-centos-2011.07.02-x86_64.img
euca-upload-bundle -b image_bucket -m /tmp/euca-centos-2011.07.02-x86_64.img.manifest.xml
euca-register image_bucket/euca-centos-2011.07.02-x86_64.img.manifest.xml
euca-bundle-image -i initrd-2.6.27.21-0.1-xen --ramdisk true
euca-upload-bundle -b initrd_bucket -m /tmp/initrd-2.6.27.21-0.1-xen.manifest.xml
euca-register initrd_bucket/initrd-2.6.27.21-0.1-xen.manifest.xml
I try and start the instance with:
euca-run-instances -t c1.medium emi-70401685
Xen fails to start instance with:
[2012-02-11 14:29:54 xend 3559] INFO (image:139) buildDomain os=linux dom=10 vcpus=1
[2012-02-11 14:29:54 xend 3559] DEBUG (image:208) domid = 10
[2012-02-11 14:29:54 xend 3559] DEBUG (image:209) memsize = 256
[2012-02-11 14:29:54 xend 3559] DEBUG (image:210) image = /usr/local/eucalyptus//admin/i-3AFB07A0/kernel
[2012-02-11 14:29:54 xend 3559] DEBUG (image:211) store_evtchn = 1
[2012-02-11 14:29:54 xend 3559] DEBUG (image:212) console_evtchn = 2
[2012-02-11 14:29:54 xend 3559] DEBUG (image:213) cmdline = root=/dev/sda1 ro
[2012-02-11 14:29:54 xend 3559] DEBUG (image:214) ramdisk = /usr/local/eucalyptus//admin/i-3AFB07A0/ramdisk
[2012-02-11 14:29:54 xend 3559] DEBUG (image:215) vcpus = 1
[2012-02-11 14:29:54 xend 3559] DEBUG (image:216) features =
[2012-02-11 14:29:54 xend.XendDomainInfo 3559] ERROR (XendDomainInfo:273) Domain construction failed
Traceback (most recent call last):
File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 266, in create
vm.initDomain()
File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 2237, in initDomain
raise VmError(str(exn))
VmError: (2, 'Invalid kernel', 'xc_dom_find_loader: no loader found\n')
[2012-02-11 14:29:54 xend.XendDomainInfo 3559] DEBUG (XendDomainInfo:2387) XendDomainInfo.destroy: domid=10
[2012-02-11 14:29:54 xend.XendDomainInfo 3559] DEBUG (XendDomainInfo:2312) UUID Created: False
[2012-02-11 14:29:54 xend.XendDomainInfo 3559] DEBUG (XendDomainInfo:2313) Devices to release: [], domid = 10
[2012-02-11 14:29:54 xend.XendDomainInfo 3559] DEBUG (XendDomainInfo:2317) Releasing PVFB front-end devices (uuid not created)...
[2012-02-11 14:29:54 xend.XendDomainInfo 3559] DEBUG (XendDomainInfo:2325) Releasing PVFB backend devices ...
[2012-02-11 14:29:54 xend 3559] ERROR (SrvBase:88) Request create failed.
Traceback (most recent call last):
File "/usr/lib64/python2.4/site-packages/xen/web/SrvBase.py", line 85, in perform
return op_method(op, req)
File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDomainDir.py", line 82, in op_create
raise XendError("Error creating domain: " + str(ex))
XendError: Error creating domain: (2, 'Invalid kernel', 'xc_dom_find_loader: no loader found\n')
WHY!?!!?! I'm following the directions. Even googling this returns almost nothing. Am I the only person in the universe having this issue?
Holy crap this documentation is bad. Why does this page http://open.eucalyptus.com/wiki/Euca2oolsImageManagement not talk about setting the kernel or ramdisk AT ALL!?!?!?
Ok, something is seriously screwed up with Eucalyptus.
I just copied the image file, the kernel and the ramdisk to the Xen Server, created a xen config file and booted the damn thing just fine!
CentOS release 5.6 (Final)
Kernel 2.6.27.21-0.1-xen on an x86_64
localhost login:
Why doesn't eucalyptus boot it???
On the nc under /usr/local/eucalyptus/admin/i-33E806E:
total 2112244
-rw-r--r-- 1 eucalyptus eucalyptus 183500800 Feb 11 23:04 ephemeral
-rw------- 1 eucalyptus eucalyptus 714696 Feb 11 23:04 instance-checkpoint
-rw-r--r-- 1 eucalyptus eucalyptus 2420577 Feb 11 17:34 kernel
-rw-r--r-- 1 eucalyptus eucalyptus 1077 Feb 11 23:16 libvirt.xml
-rw-r--r-- 1 eucalyptus eucalyptus 9635370 Feb 11 17:34 ramdisk
-rw-r--r-- 1 eucalyptus eucalyptus 1415577793 Feb 11 17:46 root
-rw-r--r-- 1 eucalyptus eucalyptus 536870912 Feb 11 23:03 swap
Attempting to start the domain as it is here would fail:
virsh # create /usr/local/eucalyptus/admin/i-33E806E2/libvirt.xml
error: Failed to create domain from /usr/local/eucalyptus/admin/i-33E806E2/libvirt.xml
error: POST operation failed: xend_post: error from xen daemon: (xend.err "Error creating domain: (2, 'Invalid kernel', 'xc_dom_find_loader: no loader found\\n')")
I thought it was weird that the kernel here was 2420577 bytes, while before bundling it was 2420384 bytes. The original ramdisk before bundling was 9635177, but here, after bundling it's 9635370 bytes.
So, I replaced the kernel and ramdisk files with the original ones before the bundling process. The files in this directory are now:
total 2112244
-rw-r--r-- 1 eucalyptus eucalyptus 183500800 Feb 11 23:04 ephemeral
-rw-r--r-- 1 root root 9635177 Feb 11 23:15 initrd.img-2.6.32-5-amd64
-rw------- 1 eucalyptus eucalyptus 714696 Feb 11 23:04 instance-checkpoint
-rw-r--r-- 1 eucalyptus eucalyptus 2420577 Feb 11 17:34 kernel
-rw-r--r-- 1 eucalyptus eucalyptus 1077 Feb 11 23:16 libvirt.xml
-rw-r--r-- 1 eucalyptus eucalyptus 9635370 Feb 11 17:34 ramdisk
-rw-r--r-- 1 eucalyptus eucalyptus 1415577793 Feb 11 17:46 root
-rw-r--r-- 1 eucalyptus eucalyptus 536870912 Feb 11 23:03 swap
-rw-r--r-- 1 root root 2420384 Feb 11 23:15 vmlinuz-2.6.32-5-amd64
I updated the libvirt.xml file accordingly. I attempted to start the domain again:
virsh # create /usr/local/eucalyptus/admin/i-33E806E2/libvirt.xml
Domain i-33E806E2 created from /usr/local/eucalyptus/admin/i-33E806E2/libvirt.xml
AND IT WORKS?!!?!?!? What is wrong with euca-bundle-image? Why is it broken!?!??!
I just tried to bundle on CentOS 5. Same deal. The ramdisk and kernel mysteriously get larger...
Would love to know what's causing this...
Here's another piece of data. If I try and use euca-unbundle on a freshly bundled image:
euca-unbundle -m image_bucket/euca-centos-2012.1.14-x86_64.img.manifest.xml
I get "Invalid manifest". It still seems like euca-bundle-image or euca-upload-image is _corrupting_ the images.
More data.
I tried again. The kernel locally before bundling is 2420384 bytes and the ramdisk is 9635177 bytes. I managed to get s3cmd working with Eucalyptus to give me a little more visibility into what's going on.
Here's the contents of my bucket after bundling and uploading everything.
LUMACDGARSTANG:s3cmd-0.9.8.3 dgarstang$ ./s3cmd ls s3://bucket1
Bucket 'bucket1':
2012-02-12 17:08 6395 s3://bucket1/euca-centos-2012.1.14-x86_64.img.manifest.xml
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.0
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.1
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.10
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.11
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.12
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.13
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.14
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.15
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.16
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.17
2012-02-12 17:08 7309072 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.18
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.2
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.3
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.4
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.5
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.6
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.7
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.8
2012-02-12 17:08 10485760 s3://bucket1/euca-centos-2012.1.14-x86_64.img.part.9
2012-02-12 17:06 3488 s3://bucket1/initrd.img-2.6.32-5-amd64.manifest.xml
2012-02-12 17:06 9614352 s3://bucket1/initrd.img-2.6.32-5-amd64.part.0
2012-02-12 17:05 3480 s3://bucket1/vmlinuz-2.6.32-5-amd64.manifest.xml
2012-02-12 17:05 2397488 s3://bucket1/vmlinuz-2.6.32-5-amd64.part.0
According to s3cmd, the size of the kernel has shrunk from 2420384 bytes to 2397488 bytes, and the ramdisk shrunk from 9635177 bytes to 9614352 bytes. Why!?!?!?
On the nc, under the /usr/local/eucalyptus/admin/i-28610673 directory, the kernel is 2420577 bytes and the ramdisk is 9635370 bytes.
Oh my god... they changed again? So, the kernel was originally 2420384 bytes, but according to s3cmd it's shrunk to 2397488, while on the nc, it's grow again to 2420577 bytes, which is still different to the original size!
Keep in mind, that as I said earlier, if I copy the ramdisk and kernel directly to the nc and replace the ones created there, it ALL WORKS.
This is nuts.
Let me try addressing some of the questions you raised.
The starter images and archived certified images are different, mostly by age. The archived are older versions of those distros. The starter images are the newest we've put together and done testing with. Those are the ones I'd recommend unless you would prefer rolling your own images.
The comment about the user guide is valid. However the guide is correct in not talking about uploading kernel and ramdisk because that's something only an admin can do. Those things are covered in a simliar section in the admin guide.
Now, one thing that should be addressed here is using the --kernel and --ramdisk options in the euca-bundle-image command. Doing it without those makes the image default to the default kernel/ramdisk for the cloud. When issuing the euca-run-instances command, the kernel and ramdisk can be overridden.
I'll reply again if I can help more as I read through this thread.
Can I ask what version of euca2ools you are using? Run euca-version.
dkavanagh: I wasn't originally, but t am now passing the --kernel and --ramdisk options to the euca-bundle-image command.
Here's what I used most recently:
euca-bundle-image -i vmlinuz-2.6.32-5-amd64 --kernel true
euca-upload-bundle -b kernel_bucket -m /tmp/vmlinuz-2.6.32-5-amd64.manifest.xml
euca-register kernel_bucket/vmlinuz-2.6.32-5-amd64.manifest.xml
euca-bundle-image -i initrd.img-2.6.32-5-amd64 --ramdisk true
euca-upload-bundle -b initrd_bucket -m /tmp/initrd.img-2.6.32-5-amd64.manifest.xml
euca-register initrd_bucket/initrd.img-2.6.32-5-amd64.manifest.xml
euca-bundle-image -i euca-centos-2012.1.14-x86_64.img --kernel eki-A9CC13BC --ramdisk eri-EACD14AA
euca-upload-bundle -b image_bucket -m /tmp/euca-centos-2012.1.14-x86_64.img.manifest.xml
euca-register image_bucket/euca-centos-2012.1.14-x86_64.img.manifest.xml
How's that look?
euca-version returns 'main-31337 2009-04-04'.
Douglas.
Douglas,
The commands look fine. My main concern is with euca2ools. I know that in Nov of 2010, I rewrote the bundling code to ensure we were compatible with EC2 in every way. I know there were problems that caused the size to be off as well. I'm not certain which version you have based on that string, but if that date's any indicator, I'd suspect euca2ools.
Did you get this from one of the distro repos, or from us? Try pulling from one of the links here first: http://open.eucalyptus.com/downloads
I can also recommend getting the latest from launchpad (or even github) and installing from source. It's super easy if you don't mind running a few commands.
David
dkavanagh: Well. that's weird. I downloaded euca2ools from source on the web site here http://open.eucalyptus.com/downloads.
To verify, I just did it again. When I run euca-version directly from the downloaded location, I get
LUMACDGARSTANG:bin dgarstang$ /Users/dgarstang/Downloads/euca2ools-1.3.1/bin/euca-version
main-31337 2009-04-04
If there was a release in 2010, something is wrong. You guys might wanna check the web site...
Um... I had NO IDEA that the tools where on github.... did I miss that in the docs? C'mon, seriously... I know I'm using open source verso here, but....
Doug.
Well, I just installed the latest euca2ools from github. Installs cleanly, Attempt to run euca2ools yields:
LUMACDGARSTANG:euca2ools dgarstang$ euca-version
Traceback (most recent call last):
File "/usr/local/bin/euca-version", line 5, in
pkg_resources.run_script('euca2ools==2.0.0', 'euca-version')
File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 489, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 1214, in run_script
exec script_code in namespace, namespace
File "/Library/Python/2.7/site-packages/euca2ools-2.0.0-py2.7.egg/EGG-INFO/scripts/euca-version", line 37, in
File "build/bdist.macosx-10.7-intel/egg/euca2ools/commands/eucacommand.py", line 43, in
File "build/bdist.macosx-10.7-intel/egg/euca2ools/nc/auth.py", line 35, in
ImportError: No module named auth_handler
*sigh*
Progress. Had to update boto (also from github)
LUMACDGARSTANG:boto dgarstang$ euca-version
Version: 2.0.0 (BSD)
Back to square one. Using the latest euca2ools (Version: 2.0.0 (BSD) from git hub did not help.
My original local files:
-rw-r--r--@ 1 dgarstang staff 1415577600 Jan 14 15:47 euca-centos-2012.1.14-x86_64.img
-rw-r--r--@ 1 dgarstang staff 9635177 Dec 28 14:51 initrd.img-2.6.32-5-amd64
-rw-r--r--@ 1 dgarstang staff 2420384 Dec 28 14:51 vmlinuz-2.6.32-5-amd64
Files on the nc:
-rw-r--r-- 1 eucalyptus eucalyptus 3483 Feb 12 10:14 kernel-digest
-rw-r--r-- 1 eucalyptus eucalyptus 2420577 Feb 12 10:14 kernel
drwxr-xr-x 8 eucalyptus eucalyptus 4096 Feb 12 10:14 ..
-rw-r--r-- 1 eucalyptus eucalyptus 6407 Feb 12 10:14 root-digest
-rw-r--r-- 1 eucalyptus eucalyptus 3491 Feb 12 10:14 ramdisk-digest
-rw-r--r-- 1 eucalyptus eucalyptus 9635370 Feb 12 10:14 ramdisk
-rw-r--r-- 1 eucalyptus eucalyptus 1415577793 Feb 12 10:17 root
-rw-r--r-- 1 eucalyptus eucalyptus 536870912 Feb 12 10:20 swap
-rw-r--r-- 1 eucalyptus eucalyptus 183500800 Feb 12 10:21 ephemeral
-rw-r--r-- 1 eucalyptus eucalyptus 1043 Feb 12 10:21 libvirt.xml
-rw------- 1 eucalyptus eucalyptus 714696 Feb 12 10:21 instance-checkpoint
The ramdisk has grown from 9635177 to 9635370 bytes, and the kernel has grown from 2420384 to 2420577 bytes.
Commands used:
euca-bundle-image -i vmlinuz-2.6.32-5-amd64 --kernel true
euca-upload-bundle -b bucket1 -m /tmp/vmlinuz-2.6.32-5-amd64.manifest.xml
euca-register bucket1/vmlinuz-2.6.32-5-amd64.manifest.xml
euca-bundle-image -i initrd.img-2.6.32-5-amd64 --ramdisk true
euca-upload-bundle -b bucket1 -m /tmp/initrd.img-2.6.32-5-amd64.manifest.xml
euca-register bucket1/initrd.img-2.6.32-5-amd64.manifest.xml
euca-bundle-image -i euca-centos-2012.1.14-x86_64.img --kernel eki-0C4F1110 --ramdisk eri-42E611F2
euca-upload-bundle -b bucket1 -m /tmp/euca-centos-2012.1.14-x86_64.img.manifest.xml
euca-register bucket1/euca-centos-2012.1.14-x86_64.img.manifest.xml
ec2-run-instances -t m1.small emi-C7681404
Absolute insanity!
Well, I just installed the latest euca2ools from github on a fresh CentOS box and tried to bundle and upload again. Same problem. I can't draw any conclusion after all this effort except that the bundling process is broken.
I should have ask before, but what version of Eucalyptus are you running? I've used the same process to bundle that centos image on 2.0.3 and 3.0 and fired up images under xen.
dkavanagh: Eucalyptus version 2.0.3. I followed the installation instructions and added a yum repo... was that the right way to do it, or were the docs wrong there too?
*sigh*
Well, all I can think of right now is to tear the whole thing down and start again.
After a fresh install, running
/usr/sbin/euca_conf --register-walrus 172.16.99.13
yields:
[root@fc01 home]# /usr/sbin/euca_conf --register-walrus 172.16.99.136
Adding WALRUS host 172.16.99.136
Trying rsync to sync keys with "172.16.99.136"...usage: ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-i identity_file] [-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-w tunnel:tunnel] [user@]hostname [command]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(600) [sender=3.0.6]
failed.
Trying scp to sync keys with "" (user "eucalyptus")...
Could not create directory '/home/eucalyptus/.ssh'.
The authenticity of host '172.16.99.136 (172.16.99.136)' can't be established.
RSA key fingerprint is fb:38:66:a8:ee:b1:4e:2e:3b:5d:13:0d:6c:d2:3c:da.
Are you sure you want to continue connecting (yes/no)?
Why? This isn't what happened on the first 3 installs.
I just tried to install the tools on a fresh system. I added the following to /etc/yum.repos.d/eucatools.repo
[euca2ools]
name=Euca2ools
baseurl=http://www.eucalyptussoftware.com/downloads/repo/euca2ools/nightly/main/centos/5/x86_64
enabled=1
I then did a "yum install euca2ool".... installed fine.
Ran euca-version, and got:
[root@adm01 yum.repos.d]# rpm -qa | grep euca
euca2ools-1.3.2-0.4.bzr339
[root@adm01 yum.repos.d]# euca-version
main-31337 2009-04-04
Isn't this the old version? Does ANYTHING work with Eucalyptus?!?!!?
Doing a package install is just fine. I've done that myself. I wrote http://open.eucalyptus.com/try/faststart which is a scripted installer that does the install and also installs a guest image. It sounds like almost an identical setup to what you're trying to do (CentOS 5, XEN). Are you running 2 nodes (one front end, one NC)? I believe that version of euca2ools should be just fine. I just wan't sure about that version string.
While 2.0.3 is a bit old now, I've run it a lot and so have many customers. I think it's just a matter of figuring out what's going on with your setup. We generally have a lot of people in IRC. I know you popped in there a little while today, but when I went to reply, I think you'd just signed off. I think the weekends are a little slow, but generally there are people there who can help (both euca folks and community folks). I'll post the link to this thread there now and see if someone can have a look.
David
Hi ,
Regarding this issue you need to update your rsync package.
yum -y update rsync
and try again. Hope it helps.
Cheers!
Deependra
Hi dgarstang,
The difference between archived EMIs and Starter EMIs is that the archived EMIs are older and outdated images. The starter EMIs give you a little bit more with being more up-to-date distros, and also allowing you to utilize the user-data option when you launch an instance from those images.
Apologies for the confusion. Do you have any suggestions on how we could make this less confusing? We labeled the starter images as based because we figured it would be less restricting. For example, the CentOS image, if you do "yum upgrade" once you launch the image as an instance, it will update the instance from 5.5 to 5.7.
The errors that you are seeing with the hypervisor, when you ran euca-run-instance, I didn't see you pass the kernel and ramdisk needed for that EMI. I may be wrong here, but when you registered the EMI, you just ran this command correct:
euca-bundle-image -i euca-centos-2011.07.02-x86_64.img
If this is the case, since you didn't define a default kernel and ramdisk to use with that EMI when you bundled the image, you need to define it when you do euca-run-instance by passing the --kernel and --ramdisk . *NOTE* You only need to do this if you have a default kernel and ramdisk showing in the Admin WebUI, under the Configuration tab.
Also, in the logs on the NC, can you paste all the information about the kernel, ramdisk and image being downloaded from Walrus. This will provide us some additional information to help troubleshoot this for you.
Once again, sorry about your frustrations. Hope this helps.
Regards,
Harold Spencer Jr.
Support Engineer, Eucalyptus Systems, Inc.
Hi Doug,
If you are able to reproduce the size change problem, it would be really helpful to see three things:
- /var/log/eucalyptus/nc.log from the node controller; it might show some evidence of a problem downloading
- a copy of the original kernel file
- a copy of the wrong kernel file, stolen from /usr/local/eucalyptus/instances/ after the image fails to boot.
-Tim
Hi dgarstang,
Sorry, I missed a few of the later postings and I see that you began to pass the kernel and ramdisk when bundling the image.
To help troubleshoot whats happening on the NC, can you include your NC log?
Thanks, and sorry for the late follow-up.
Regards,
Harold Spencer, Jr.
Support Engineer, Eucalyptus Systems, inc.
David, so... where do I get the latest stable euca2ools (why is the T missing anyway?) as an RPM from? Rather than me root around trying to find it, I'd rather just have you tell me where it is.
I've rebuilt everything from scratch. Attempting to reproduce...
Doug.
I installed both the front end (one server), and the node controller (another server) from scratch. For this test, I'm still using the same client side Amazon EC2 and euca2ools commands. By the way, it would be nice if the documentation stated somewhere that anything except a certain old version of the Amazon ec2-api-tools wouldn't work... I spent a day on that.
euca-bundle-image -i vmlinuz-2.6.27.21-0.1-xen --kernel true
euca-upload-bundle -b bucket2 -m /tmp/vmlinuz-2.6.27.21-0.1-xen.manifest.xml
euca-register bucket1/vmlinuz-2.6.27.21-0.1-xen.manifest.xml
(got eki-370E11B2)
euca-bundle-image -i initrd-2.6.27.21-0.1-xen --ramdisk true
euca-upload-bundle -b bucket2 -m /tmp/initrd-2.6.27.21-0.1-xen.manifest.xml
euca-register bucket2/initrd-2.6.27.21-0.1-xen.manifest.xml
(got eri-18FF112B)
euca-bundle-image -i euca-centos-2011.07.02-x86_64.img --kernel eki-370E11B2 --ramdisk eri-18FF112B
euca-upload-bundle -b bucket2 -m /tmp/euca-centos-2011.07.02-x86_64.img.manifest.xml
euca-register bucket2/euca-centos-2011.07.02-x86_64.img.manifest.xml
(got emi-D7FA142F)
ec2-run-instances -t m1.small emi-D7FA142F
RESERVATION r-43730771 admin admin-default
INSTANCE i-47620863 emi-D7FA142F 0.0.0.0 0.0.0.0 pending 0 m1.small 2012-02-13T03:55:59+0000 cluster01 eki-370E11B2 eri-18FF112B
The problem still occurs. How do you want these log files? Can I attach files to here?
Doug.
Yeah you can tar and zip /var/log/eucalyptus/ from both NC and the front end and attach here for us to have a look.
Well... I got the logs but I don't see a way to attach them to this thread...
Can you try using something like: http://wikisend.com/ -- I don't think files can be attached here.
Okidoki...
The log files are at:
http://wikisend.com/download/255542/eucalyptus-logs-fe.tgz
http://wikisend.com/download/470538/eucalyptus-logs-nc.tgz
Doug.
Progress!!!
Thanks! OK, some quick analysis. The front-end sees these files for the kernel and ramdisk:
cloud-output.log.2:19:32:26 INFO 782 WalrusImageManager | Cached image: bucket1/initrd-2.6.27.21-0.1-xen.manifest.xml size: 6260962
cloud-output.log.2:19:31:04 INFO 782 WalrusImageManager | Cached image: bucket1/vmlinuz-2.6.27.21-0.1-xen.manifest.xml size: 2231898
and the node controller appears to download them correctly:
[Sun Feb 12 19:37:14 2012][004501][EUCADEBUG ] walrus_request(): wrote 2231898 bytes in 176 writes
[Sun Feb 12 19:37:14 2012][004501][EUCAINFO ] walrus_request(): saved image in /usr/local/eucalyptus//admin/i-3A6F06FB/kernel
[Sun Feb 12 19:37:33 2012][004501][EUCADEBUG ] walrus_request(): wrote 6260962 bytes in 436 writes
[Sun Feb 12 19:37:33 2012][004501][EUCAINFO ] walrus_request(): saved image in /usr/local/eucalyptus//admin/i-3A6F06FB/ramdisk
Now I'd check the actual size of the files on disk...first of all, can you look in /var/lib/eucalyptus/bukkits/bucket1/ and make sure there are two files with those matching sizes? They will be stored in encoded filenames, but you should see the file sizes match.
Then check on the NC in /usr/local/eucalyptus/instances/admin// to see that the kernel and ramdisk files match. If they don't match, something really weird is going on. If the file sizes match, we've probably got a hypervisor configuration issue.
So, I actually got this to finally work.
I installed a fresh new VM with CentOS 5 and used the most recent link that David sent for the euca2ools. That has to be what made the difference. I think installing from source on my mac had somehow kept an old version around. The fact that the version number returned by the euca-version command doesn't match the version in the file name really doesn't help!
My brain is a bit fried right now, but to be completely honest, the client side tools are a mangled mess. The stuff at http://downloads.eucalyptus.com/software/euca2ools/2.0/ is all over the place, not categorized very well and just plain hard to decipher. I ended up using the rpm link that David gave me, but earlier he suggested I get the code for euca2ools from github, which isn't even mentioned on the web site.
Also, having the tools in python rather than java also complicates matters, as you need a specific version of python and so on, which means installing those dependancies from source, or maybe RPM's. Ugh.
Anyway, I was able to boot the instance and log into it, and do a few other basic things. There's still kinks though. The ec2-create-volume command was hanging, while euca-create-volume worked fine.
In general, it would be nice if the client side tools kept pace too. I had to patch s3cmd to get it to work, use a specific arbitrary version of ec2-api-tools, and there was this mess with euca2ools.
Is the Enterprise version documentation and packaging better? Does the Enterprise version support tags?
Thanks all for your effort.
Doug.
It's working. I'd love to say what I did, and provide constructive feedback but your damn spam filter keeps stopping me!!!!!
Happy to hear that you are up and running now.
Thank you for the update and feedback Doug. All of the feedback (client tools, state of downloads, ham as spam issue) is appreciated.
My apologies for running you through the ringer on the spam filtering.
Best,
Ian
Hi Doug,
Regarding the questions about enterprise version starting with eucalyptus 3 there is going to be only 1 version or rather called as the eucalyptus platform. It is going to be free and open source software.
It will have commercia plugins as part of it for those who need them.
Regarding documentation, packages etc. I can assure that the new website will cover those things in a much better way and it will definitely be obvious (certain things which you pointed out here).
Regarding tags I believe you mean ec2 tagging feature mentioned here , I believe it is not part of eucalyptus as of now.
Thanks for sharing with us your experience of eucalyptus. We take all the feedback in positive way and continue to improve.
Cheers!
Deependra