Hi everyone. Unfortunately, when I try to launch the 64-bit Fedora 14 AMI (ami-e291668b) as a m2.xlarge, m2.2xlarge, or m2.4xlarge instance, the instance is unresponsive. Amazon has confirmed that it is due to a kernel panic (please see https://forums.aws.amazon.com/message.jspa?messageID=212820#212820 for details).
Could anyone take a look at this? Let me know if there is any further information I can provide.
We are pleased to announce a new release of Deltacloud Cloud Engine.
This is an incremental release with some updates to the pre-beta release
made available in November. Some of the key updates include:
* Code refactoring and bug fixes for Provider views
* Code refactoring and bug fixes for Accounts views
* Code refactoring and bug fixes for Users views
* Support for mapping between Provider Hardware Profiles and Aeolus
* Object Browser Initial Layout
Deltacloud Cloud Engine (formerly Deltacloud Aggregator) provides a web
UI in front of the Deltacloud API to allow for the management and
monitoring of cloud images across multiple providers.
If you are interested in taking Cloud Engine for a spin, installation
instructions  and a usage guide  are available to help you get
Bug reports can be filed under the 'Cloud Engine' component at
bugzilla.redhat.com. There is a a project contributor  page that
will help you get involved in testing, documenting, reporting issues,
and contributing code patches to the project.
There are a group of us inside of RedHat working on a number of cloud
related projects. I'd like to get a bit more visibility to these projects, so
I'm going to make a few announcements on this list. The idea is to keep up
with these announcements and get more participation.
The first project I'd like to point out is my own "oz" project.
The main goal of this project is to be able to do fully unattended installs
of guest OSs. Though this isn't strictly tied to the cloud, it is one of the
foundations of being able to go all the way from a blank diskimage to a
running instance in, say, EC2.
Oz works by using the native installer from the various OSs along with
the appropriate kickstart or other autoattend file. In order to minimize the
possibility of errors, the initial guest that is created is Just Enough
Operating System (JEOS). Assuming the installation of the JEOS is successful,
then the guest can be fired up to do further automatic customization (there is
prototype code to do this, but it doesn't really work yet).
Oz is written as a set of re-usable python classes. There is a front-end
to oz called oz-install that takes in a piece of XML (which we call the TDL
for Template Description Language), which defines the OS. Note that this
XML format is still somewhat in flux, so it may change in the near future.
If you want to take a look at the Oz code, it is available at:
https://github.com/clalancette/oz. If there is enough interest in it, I can
also setup a mailing list.
Questions, comments, and criticisms are welcome!
Hey everyone --
After fighting with too many different tools where none of them acted like I
wanted last week, I've gone ahead and put together a simple app that uses
all of the python-imgcreate stuff to generate an image that's usable for
an AMI in EC2. Very simple: kickstart file in, disk image out. I still
need to put in the pieces to auto-bundle and upload the image if desired,
but at this point, it's already very useful to me at least. If others find
it useful, I can take the next steps of packaging it up for Fedora, etc.
git repo at
announcement blog post at
 Same base pieces as livecd-creator and lives in the same source repo.
Re-looking at this again; I noted in the meeting that a new multipart upload
feature was created for S3, which means anything that hasn't been changed to
use it (it's been out just a couple weeks) is now sorely outdated; that
feature is too big an improvement to ignore. Additionally, most of the
tools I've used simply can't handle large amounts of data very well, and the
S3 mirror is indeed a decent amount of data. I'll re-review s3cmd
That said, was anything new added or removed from the spec of what the tool
needs to do since whenever that was?
On the 32 bit AMI for Fedora 14, I get the following warning in
/var/log/messages when mounting XFS volumes:
# spin up 32 bit ami on m1.small and login
$ yum install xfsprogs syslog
$ umount /mnt
$ mkfs.xfs /dev/xvda2 #IIRC, or else whatever was mounted to /mnt
$ mount /dev/xvda2 /mnt
# see the warning in /var/log/messages
In the logs, you'll see this stack trace several times after mounting
an XFS volume, either from ephermeral/instance storage or an EBS
volume. It does not occur when you mount a loop device formatted as
XFS, nor does it occur with any other filesystem that I've seen.
The error does not occur on the x86_64 architecture.
It has the same message as mentioned at the top of
https://bugzilla.redhat.com/show_bug.cgi?id=632802 but further reading
of that issue does not make me think it's the same problem. I would
imagine this same issue occurs running in any Xen environment where
the domU is a recent kernel, but I don't have a way to verify this.
Is this a bug? If so, what component should I enter it under?