default karmic image from image-store doesn't run on default m1.small

Bug #529056 reported by Boris Devouge
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
eucalyptus (Ubuntu)
Confirmed
Low
Unassigned
Lucid
Won't Fix
Low
Unassigned

Bug Description

This bug does not present a good initial experience to UEC new commers:

- When running the first instance, downloading the default Ubuntu 9.10 image from the Image Proxy, and try to simply launch it with all default settings, fails to run the instance.

It seems the disk reservation from the instance _needs_ to be superior to the EMI fs size.
So when a emi has a fs of 2 gb, we should make a reservation for 3 gb for the instance to run, as a 2gb reservation will fail.

Revision history for this message
Mathias Gug (mathiaz) wrote :

How are you trying to launch the instance with the default settings? Could you paste your command line?

Changed in eucalyptus (Ubuntu):
status: New → Incomplete
importance: Undecided → Low
Revision history for this message
Boris Devouge (bdevouge) wrote :

euca-run-instances emi-DFE5107D is the command line, after sourcing the .euca/eucarc file.

The entity testing is only plainly following the docs there:

https://help.ubuntu.com/community/UEC/CDInstall
(Specifically Chapter 7)

apart that he omitted the -t c1.medium (which, funnily, does not run the default m1.small ;-) instance size)

Doing this result in the instance starting and immediately terminating. Changing the config of m1.small to 3 gig disk and restarting the instance fixes the issue.

If there is an overhead between filesystem sizes and storage reservation on Eucalyptus, it should be taken into account and transparent to the user.

Revision history for this message
Mathias Gug (mathiaz) wrote : Re: [Bug 529056] Re: instances disk size needs to be bigger than filesystem size

On Wed, Mar 03, 2010 at 11:45:13AM -0000, Boris Devouge wrote:
> euca-run-instances emi-DFE5107D is the command line, after sourcing the
> .euca/eucarc file.
>

Could add the command line used to register the image (emi-DFE5107D)?

> apart that he omitted the -t c1.medium (which, funnily, does not run the
> default m1.small ;-) instance size)
>

I guess it's an issue with the default machine type used to start the instance.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

Revision history for this message
Boris Devouge (bdevouge) wrote :

Mathias Gug wrote:
> On Wed, Mar 03, 2010 at 11:45:13AM -0000, Boris Devouge wrote:
>> euca-run-instances emi-DFE5107D is the command line, after sourcing the
>> .euca/eucarc file.
>>
>
> Could add the command line used to register the image (emi-DFE5107D)?

This the image from the image-proxy-store. As mentionned in our docs.
The registration is automatic once the use click 'install' in the store.

>
>> apart that he omitted the -t c1.medium (which, funnily, does not run the
>> default m1.small ;-) instance size)
>>
>
> I guess it's an issue with the default machine type used to start the
> instance.

That is precisely the issue i am trying to highlight. There is no
difunctionality at the core here, just that the image we ship in the
store, epanded, is exactly 2 gb. When ran in the default machine type
(where disk space is set to 2 gb), the machine fails to run.

So either we need to reduce the default image size of our image shipped
in the store, or take on the little overhead in the feault 'm1.small' size.

Hope this clear things.

--
--
Boris Devouge <email address hidden>
Sales Engineer Office: +44 (0)20 7630 2476
Canonical Mobile: +44 7809 389 874
GPG FPR: ADB9 0AE9 2451 2BAD B2C7 BB2C DB22 052A 7A37 FC75

Revision history for this message
Scott Moser (smoser) wrote : Re: instances disk size needs to be bigger than filesystem size

The images have 2G filesystem. the default 'small' is "2G disk". However, swap has to be accounted for. So, if you launch an image with 2G filesystem in a instance size with 2G disk, it will fail as Borris explained above.

 I *think* that in karmic, somehow our 2G filesystems magically fit into the default m1.small disk size. I don't have that to test right now, though. We actually chose the 2G size deliberately so it would fit in all sizes.

The images can be easily resized, but at least with our lucid images, 128M (from default 'small') is too small. In my experience, the instance comes up, but with OOM messages.

Mathias Gug (mathiaz)
summary: - instances disk size needs to be bigger than filesystem size
+ default karmic image from image-store doesn't run on default m1.small
Changed in eucalyptus (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
C de-Avillez (hggdh2) wrote :

Indeed. Mathias and I just ran by the same error, and I went on and increased the disk size for m1.small from 2 to 3 G. I was then able to start the image.

This was done on Lucid Eucalyptus, running the Karmic image from the store.

Revision history for this message
Scott Moser (smoser) wrote :

The plan here is to:
a.) leave m1.small disk size at 2G. modify lucid filesystem image to be 1.4G in size. This will allow lucid images to fit into the 2G image and include the 512M of swap that is added to the image. The size units in Eucalyptus are in 1G units, keeping this at 2G rather than setting it at 3G will make installs faster.
b.) set the m1.small memory size to 192M

filesystem is easily resized up with uec-resize-image.

The negative affects of the above are:
a.) karmic images from the image store will still not fit into m1.small (the do not at the moment, so no change).
b.) lucid image installs from the image store will have a 1.4G root filesystem rather than a 2G root filesystem that was in karmic.

Revision history for this message
Scott Moser (smoser) wrote :

see also bug 544292

Revision history for this message
Scott Moser (smoser) wrote :

just for reference, a 'df' of a 2G lucid image looks like:
$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda 2.0G 646M 1.3G 34% /

So even moving the size to 1.4G you'd still get ~ 700M to work in.

Revision history for this message
Scott Moser (smoser) wrote :

using lucid server image 20100323,
$ cat /proc/partitions
major minor #blocks name
   8 0 2126848 sda
   8 1 1441792 sda1
   8 2 88000 sda2
   8 3 597023 sda3

$ euca-describe-availability-zones verbose
AVAILABILITYZONE UEC-TEST1 10.1.1.71
AVAILABILITYZONE |- vm types free / max cpu ram disk
AVAILABILITYZONE |- m1.small 0000 / 0002 1 192 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

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

I'm going to mark this won't-fix for now.

I don't believe the Karmic images are going to be of primary value much longer. Surely people will bump up to 10.04 images soon. And we have now fixed the Lucid images to fit in 2G and set the default m1.small MEM to 192M, and tested that Lucid images run well.

Changed in eucalyptus (Ubuntu Lucid):
status: Confirmed → Won't Fix
Revision history for this message
Boris Devouge (bdevouge) wrote : Re: [Bug 529056] Re: default karmic image from image-store doesn't run on default m1.small

Agreed for Karmic.
It was mainly filed to make sure we test the most common and rapid way
to 'try' UEC which is to download and launch the 'default' image from
the store, and run it in the default instance size.

Is 192 meg a requisite for current uec lucid images?

Revision history for this message
Scott Moser (smoser) wrote : Re: [Bug 529056] Re: default karmic image from image-store doesn't run on default m1.small

On Thu, 25 Mar 2010, Boris Devouge wrote:

> Agreed for Karmic.
> It was mainly filed to make sure we test the most common and rapid way
> to 'try' UEC which is to download and launch the 'default' image from
> the store, and run it in the default instance size.
>
> Is 192 meg a requisite for current uec lucid images?

I believe any official server documentation will say 256. However, I've
run with 192 and not seen any OOM messages. I think that 128 will have
OOM messages on boot.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.