UEC broken with upgrade.

[pnunn]

Anybody??? Has anyone actually got this working??

I have found some information on the eucalyptus forum that seems to relate

http://open.eucalyptus.com/forum/ebs...linux-instance

but no joy with my setup.

I can't see any sign of the disk hitting the instance in dmesg or anywhere else.

Who can I talk to about this?? Please??

[pnunn]

OK I give up. Looks like no one is interested. UEC on 10.10 is broken. STAY AWAY... I now can't log in to any instance running (ssh connection refused). I had none of these issues with 10.04. Looks like I roll back, or try some other distro for this.

Peter.

[pallaire]

Hello PNUNN,

I am having the same difficulties that you were having ... did you find a solution ?

I am at the same point ... going back to 10.04 LTS or starting from scratch with the sources.

My current state is that I have a NC installed, which is registered on the CC, but from the NC machine (not an instance) I cant access the web at all!

So, on the NC, I cant do

apt-get update
apt-get install ntp
apt-get upgrade eucalyptus


Its like the iptables is not working on the CC ... I have never had this problem on 10.04 ... but I need to upgrade to euca 2.x

thanks

[pallaire]

Hello PNUNN,

I found some problems with 10.10 ... but I was able to debug enough to have a working setup. So may be you will be interested in what I found ...


1. Images using SCSI are not working!
2. Qcow2 images are not working in 10.10 ... they were in 10.04 LTS
3. Splited front end setup is not working in 10.10 ... it was in 10.04 LTS

About problem #1 and #2:

All my problems were happening with my Windows XP image, it was working fine in 10.04 LTS, but I could not connect to them in 10.10! At first glance, I thought it was an iptables problem, but in fact, the problem was that the instance was never really running. Windows was stuck in its DOS mode telling me it could not boot. This error was not written to the console output, so if I ever did a "euca-get-console-output", I would get nothing. To find that error I had to debug directly on the node. I installed a minimal xorg on the NC and debugged following this procedure: http://cssoss.wordpress.com/2010/05/...ing-instances/ so on the NC were my instance was trying to start I would attach vncviewer to the instance!

Bug #1 ... they way that eucalyptus/libvirt create the SCSI device in 10.10 ... is really more complicated than any tutorial out there that show you how to create an image. In the tutorial, the scsi drive parameter is: -drive file=./disk,if=scsi,boot=on,index=1

The instance will receive : -device lsi,id=scsi0,bus=pci.0,addr=0x4 -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -drive file=./disk,if=none,id=drive-scsi0-0-0,boot=on,format=raw

Somewhere in this huge line, Windows Scsi driver is not working, it won’t boot with that, I tried this line manually with kvm, and I can reproduce the bug.

How to go around this bug? Use the IDE interface instead. To do that you will need to modify this file : /usr/share/eucalyptus/gen_kvm_libvirt_xml

Change that : <target dev='sda'/>
To that : <target dev='hda'/>


Bug #2 ... After fixing the bug #1, I was still not able to boot, I found the qcow2 format images are not supported in this version of libvirt/qemu/kvm !!!! How to go around that? Convert your image back to raw.

qemu-img -f qcow2 -O raw disk disk.raw

Then re-bundle/upload/register your image and it will work!

One way to validate that your cloud is working fine is to use an image created by Ubuntu, you can find them there: http://uec-images.ubuntu.com/ Once you know that the cloud is working you can try to make other images work on it.


Bug #3 ... I have not found a fix for this bug on 10.10 (this bug does not exist in 10.04), if you put the CLC+Walrus on one server, the CC+SC on another server, then a NC (or many) on another machine ... the instances won’t be able to talk to the walrus to download the files (kernel,boot,image) so the instances will be pending forever! There is something wrong with the way 10.10 Clusters manage the iptables, the NC cannot talk to the walrus, and it can only talk to the CC machine. You won’t see this bug if you follow every tutorials out there, because they are all a copy of the same tutorial that was made using only one machine as the front end (CLC+Walrus+CC+SC on one computer) Since the NC is limited to talk to the CC's computer, in this setup it’s the same machine as the Walrus, so it is working. I will try to contact eucalyptus about that.