I have the exact same issue. First thought it was my image bundling so i have test using one of eucalyptus certified images (euca-centos-5.3-i386.tar.gz). Is the manifest corrupted in some way? No idea. But my images shows off from euca-describe-images.

# euca-version
1.2-31337 2009-04-04

Here is the trace from the cloud-error.log

17:29:52 [DefaultServiceExceptionStrategy:FinishedVerify.9] ERROR
********************************************************************************
Message : Component that caused exception is: FinishedVerify. Message payload is of type: VmAllocationInfo
Type : org.mule.api.service.ServiceException
Code : MULE_ERROR--2
Payload : edu.ucsb.eucalyptus.cloud.VmAllocationInfo@10e6bf6
JavaDoc : http://mule.mulesource.org/docs/apidocs/org/mule/api/service/ServiceExce...
********************************************************************************
Exception stack is:
1. Cannot get property 'value' on null object (java.lang.NullPointerException)
org.codehaus.groovy.runtime.NullObject:56 (null)
2. Cannot get property 'value' on null object (com.eucalyptus.util.EucalyptusCloudException)
com.eucalyptus.sla.VmAdmissionControl:143 (null)
3. Component that caused exception is: FinishedVerify. Message payload is of type: VmAllocationInfo (org.mule.api.service.ServiceException)
org.mule.component.DefaultLifecycleAdapter:214 (http://mule.mulesource.org/docs/apidocs/org/mule/api/service/ServiceExce...)
********************************************************************************
Root Exception stack trace:
java.lang.NullPointerException: Cannot get property 'value' on null object
at org.codehaus.groovy.runtime.NullObject.getProperty(NullObject.java:56)
at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:154)
at org.codehaus.groovy.runtime.callsite.NullCallSite.getProperty(NullCallSite.java:29)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:237)
at com.eucalyptus.sla.LeastFullFirst.allocate(LeastFullFirst.groovy:19)
at com.eucalyptus.sla.NodeResourceAllocator.scriptedAllocator(NodeResourceAllocator.java:32)
at com.eucalyptus.sla.NodeResourceAllocator.allocate(NodeResourceAllocator.java:26)
at com.eucalyptus.sla.VmAdmissionControl.evaluate(VmAdmissionControl.java:121)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.mule.model.resolvers.AbstractEntryPointResolver.invokeMethod(AbstractEntryPointResolver.java:147)
at org.mule.model.resolvers.ReflectionEntryPointResolver.invoke(ReflectionEntryPointResolver.java:127)
at org.mule.model.resolvers.DefaultEntryPointResolverSet.invoke(DefaultEntryPointResolverSet.java:50)
at org.mule.component.DefaultLifecycleAdapter.intercept(DefaultLifecycleAdapter.java:202)
at org.mule.component.AbstractJavaComponent.invokeComponentInstance(AbstractJavaComponent.java:82)
at org.mule.component.AbstractJavaComponent.doOnCall(AbstractJavaComponent.java:73)
at org.mule.component.AbstractComponent.onCall(AbstractComponent.java:87)
at org.mule.model.seda.SedaService$ComponentStageWorker.run(SedaService.java:533)
at org.mule.work.WorkerContext.run(WorkerContext.java:310)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
at java.lang.Thread.run(Thread.java:636)

Sorry about the version confusion and about using the wrong forum. I was just trying to continue an existing thread :-)

# euca_conf -version
Eucalyptus version: 1.6.2

I am using eucalyptus through Ubuntu Enterprise Cloud installation with mostly vanilla setup for experimentation purpose.

I am not quite sure about the status of component registration. But I think I didn't had the cc and sc components properly registered. On the other hand, Walrus was definitively up since I have been successful in interacting with the service through s3 tools. So I guess that would explain why the image bundling was operational.

Now that I have properly registered the cc and sc components, I don't get the null pointer exception. (Other error but that's another story which I have to find out).

As a suggestion, maybe the error handling on run-instances could be enhanced to inspect if both sc and cc are available.

Thanks