Open Thoughts

Kiran Murari

Subscribe to Kiran Murari: eMailAlertsEmail Alerts
Get Kiran Murari: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Cloudonomics Journal, Open Source Journal, Open Source and Cloud Computing, CIO/CTO Update

Blog Post

Eucalyptus: Not Enough Resources - VM Instances

This issue arises if the node controller is not registered with the cluster controller

Cloud Expo 2010 East in New York

Issue:

FinishedVerify: Not enough resources: vm instances.

Reasoning:

This issue arises if the node controller is not registered with the cluster controller or if there are no free VMs available to launch the instance.

Solution:

In case, the node controller is not registered, the output of “euca-describe-availability-zones verbose” will show zero free and max VMs as below.

$ euca-describe-availability-zones verbose
 AVAILABILITYZONE        mycloud       A.B.C.D
 AVAILABILITYZONE        |- vm types     free / max   cpu   ram  disk
 AVAILABILITYZONE        |- m1.small     0000 / 0000   1    128     2
 AVAILABILITYZONE        |- c1.medium    0000 / 0000   1    256     5
 AVAILABILITYZONE        |- m1.large     0000 / 0000   2    512    10
 AVAILABILITYZONE        |- m1.xlarge    0000 / 0000   2   1024    20
 AVAILABILITYZONE        |- c1.xlarge    0000 / 0000   4   2048    20

Register the node controller with the following command and add the discovered nodes.

$ sudo euca_conf --no-rsync --discover-nodes

Once the node is successfully registered “euca-describe-availability-zones verbose” shows the following output

$ euca-describe-availability-zones verbose
 AVAILABILITYZONE        oss-cloud       A.B.C.D
 AVAILABILITYZONE        |- vm types     free / max   cpu   ram  disk
 AVAILABILITYZONE        |- m1.small     0002 / 0002 1    128     2
 AVAILABILITYZONE        |- c1.medium    0002 / 0002 1    256     5
 AVAILABILITYZONE        |- m1.large     0001 / 0001 2    512    10
 AVAILABILITYZONE        |- m1.xlarge    0001 / 0001 2   1024    20
 AVAILABILITYZONE        |- c1.xlarge    0000 / 0000 4   2048    20

Now an instance can be successfully started (provided other network related configuration has been taken care).

But after starting a couple of instances, again if the same error is encountered, then its time to look at the MAX_CORES macro in /etc/eucalyptus.conf

For example:

Before starting any instances,

$ euca-describe-availability-zones verbose
 AVAILABILITYZONE        oss-cloud       A.B.C.D
 AVAILABILITYZONE        |- vm types     free / max   cpu   ram  disk
 AVAILABILITYZONE        |- m1.small     0002 / 0002 1    128     2
 AVAILABILITYZONE        |- c1.medium    0002 / 0002 1    256     5
 AVAILABILITYZONE        |- m1.large     0001 / 0001 2    512    10
 AVAILABILITYZONE        |- m1.xlarge    0001 / 0001 2   1024    20
 AVAILABILITYZONE        |- c1.xlarge    0000 / 0000 4   2048    20

After running two instances of type c1.medium,

$ euca-describe-availability-zones verbose
 AVAILABILITYZONE        oss-cloud       A.B.C.D
 AVAILABILITYZONE        |- vm types     free / max   cpu   ram  disk
 AVAILABILITYZONE        |- m1.small     0000 / 0002 1    128     2
 AVAILABILITYZONE        |- c1.medium    0000 / 0002 1    256     5
 AVAILABILITYZONE        |- m1.large     0000 / 0001 2    512    10
 AVAILABILITYZONE        |- m1.xlarge    0000 / 0001 2   1024    20
 AVAILABILITYZONE        |- c1.xlarge    0000 / 0000 4   2048    20

This deprives from launching further instances of any image.

MORE CORES….. MORE VMS……

In /etc/eucalyptus.conf, there sits this MAX_CORES macro which defaults to available CPU cores.

Before changing MAX_CORES and not running any instances:

$ euca-describe-availability-zones verbose
 AVAILABILITYZONE        oss-cloud       A.B.C.D
 AVAILABILITYZONE        |- vm types     free / max   cpu   ram  disk
 AVAILABILITYZONE        |- m1.small     0002 / 0002 1    128     2
 AVAILABILITYZONE        |- c1.medium    0002 / 0002 1    256     5
 AVAILABILITYZONE        |- m1.large     0001 / 0001 2    512    10
 AVAILABILITYZONE        |- m1.xlarge    0001 / 0001 2   1024    20
 AVAILABILITYZONE        |- c1.xlarge    0000 / 0000 4   2048    20

After changing MAX_CORES to 8 and not running any instances:

$ euca-describe-availability-zones verbose
 AVAILABILITYZONE        oss-cloud       A.B.C.D
 AVAILABILITYZONE        |- vm types     free / max   cpu   ram  disk
 AVAILABILITYZONE        |- m1.small     0008 / 0008 1    128     2
 AVAILABILITYZONE        |- c1.medium    0008 / 0008 1    256     5
 AVAILABILITYZONE        |- m1.large     0004 / 0004 2    512    10
 AVAILABILITYZONE        |- m1.xlarge    0003 / 0003 2   1024    20
 AVAILABILITYZONE        |- c1.xlarge    0001 / 0001 4   2048    20

Earlier, an instance of type c1.xlarge was not possible, but now one instance of c1.xlarge is possible.

So MORE CORES….. MORE VMs…..

Read the original blog entry...

More Stories By Kiran Murari

Kiran Murari works at CSS Corp. Earlier, he was into the domain of Embedded Networking and has worked on developing software for ARM and MIPS based routers, porting Linux kernel and Linux applications to various hardware platforms like Intel IXP4xx, Xscale and OMAP3. As a part of developing software for routers, he was involved in developing the firewall and IDS/IPS modules. His current interests include Virtualization, Cloud Computing and Embedded devices.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.