We’re thrilled to announce that Layerboom has been acquired by Joyent, a leading provider of Cloud Computing services and solutions. Here’s the press announcement.

It’s been a pretty fast paced life at Layerboom so far, having only been founded in May, 2009. We felt that with the competition ramping up so quickly the best way to continue with our project would be as part of a bigger team. It turns out that Joyent is a perfect fit for us and we’re really thrilled to be working on some exciting projects that you’ll no doubt hear about in the very short future.

A big thanks to Bootup & our Investors for taking a chance on a couple guys with a laptop and an idea, and a big congratulations to the Layerboom team for being persistent, forward thinking, and above all a pleasure to work with.

Cheers,

Howard Wu and Trevor Orsztynowicz

ps We’re hiring, so if you’re a developer and you’re looking for a killer opportunity send me an email.

A team at Microsoft Research has been working on measuring energy usage in IT, and has come up with a novel piece of software called Joulemeter. From the website

Joulemeter is a software based mechanism to measure the energy usage of virtual machines (VMs), servers, desktops, laptops, and even individual softwares running on a computer.

Joulemeter estimates the energy usage of a VM, computer, or software by measuring the hardware resources (CPU, disk, memory, screen etc) being used and converting the resource usage to actual power usage based on automatically learned realistic power models.

They’ll apparent be offering a download of the software. In the meantime you can read the abstract.

As a start up doing big things, when we first heard about “Under the Radar” event, we figured how are we going to get on the radar for these folks ? We sent in our application, talked with Debbie and Jasmine  to pitch our product, the now so popular BoomBox. At the end of the day, among an ocean of applications and good ideas surrounding the cloud space, LayerBoom has been chosen to present at “Under the Radar” on April 16, 2010 in Mountain View, California. So if you’re around the Bay area in mid April, we look forward to seeing you there.

It’s no secret that Layerboom is part of Bootup Labs, a “seed accelerator” helping starts ups spawn locally. As part of the Bootup family, meeting awesome people is one of the best perks that comes with this. One such awesome person arrived this week, Guy Kawasaki, the awesome guru to us in the startup world because of his great advice and feedback from listening to our start up ideas.

Guy actually spent a full day at Bootup with us, going through every company with us on a one on one basis, providing honest and sometimes brutally honest feedback. Despite all the bruised egos he left behind the office, I’m sure we’re all a little bit better and clearer on our message.  Here is a picture of Guy with the Layerboom team.

CloudCamp is finally coming to Vancouver this year on March 13th, 2010. CloudCamp is an unconference where early adopters of Cloud Computing technologies exchange ideas. With the rapid change occurring in the industry, we need a place we can meet to share our experiences, challenges and solutions. At CloudCamp, you are encouraged you to share your thoughts in several open discussions, as we strive for the advancement of Cloud Computing. End users, IT professionals and vendors are all encouraged to participate.

If you or anyone else you know is interested in attending then please head over to the CloudCamp Vancouver page and register for the event.

Interested in helping sponsor CloudCamp Vancouver? Get in touch with one of our organizers.

See you there!

Well, if you’ve been a loyal reader to this blog, you probably expect a quarterly blog from us. 2009 was a big year for LayerBoom as we got started and put our heads down into development and rarely came up for air.

Now we are in the final stages of tweaking our product, the first Virtualization/Cloud appliance product to hit the market place. So far, the responses we received from enterprises and hosting companies around the world is nothing short of amazing, with inquiries from Asia, Europe and North America.  So what is the our virtualization appliance, appropriately labeled as “The BoomBox” going to do ?

Our idea was simple, how to make cloud affordable, accesible and in general, less cloudy for everyone. The BoomBox transforms your existing infrastructure investments into a cloud computing platform. Customers get an easy to use web dashboard, billing and invoicing functionality, and the ability to manage physical and virtual infrastructure with the click of a button. Provision new servers in minutes, and integrate with your existing infrastructure management solutions with a comprehensive API.

We’re shipping da BoomBoxes in February so let us know if you’re in need of a cloud solution.

Last week Google released their source code for the Chromium project. This is the project that will become the Google OS. It’s a novel, basic approach to an operating system, geared mostly towards Netbooks and very very lightweight desktops. You log in with your Google Account and are presented with a browser. That’s it.

While the development repository and source code is available to the public, to try it out you still have to build a copy yourself.

Rather than build the image yourselves we’ve put together the image, and it runs on KVM, and in VirtualBox just fine.

Download it now over at www.layerboom.com/chromeos

Something we’ve been finding pretty frustrating lately is the whole issue of backups. On my desktop I run Dropbox, but there still isn’t a Dropbox quality (or ease of use) service for hosting companies. If you run a website / service / business you need at the very least, a disaster recovery plan, and that plan involves backups. There are several ways hosting companies deal with this.

1) They dont do them

Yeah you read that right. You don’t actually get backups. These policies are buried deep in their terms of service or usage policies. It’s totally up to you to backup your server content. If you don’t and your server crashes its the end-users problem. High profile data losses can destroy any business, especially startups.

2) Highly Available Storage

This strategy is usually combined with #1 above. Instead of backing up your data they just replicate your data across multiple drives. This means that the chances of you losing your data go down, and depending on the technology used to safeguard against drive failure, you can get really high availability. (iSCSI and ZFS come to mind). Its important to remember that RAID is NOT a backup solution, only a way to mitigate potential failures.

3) OS Level Backups

In this strategy end users are still required to worry about their own data, and choose which sets of data they backup. A hosting company will provide an end-point for you to send your backups to. If you’ve ever done managed or dedicated hosting, this is often the product that is sold. Tivoli or some other backup client is provided, but still relies on either a consultant, sysadmin or service provider to configure correctly.

4) VM Level Backups

There’s another solution that works, and it gets around a lot of the issues with OS level backups, like running a database while doing a backup, etc. Snapshot the entire virtual machine and replicate the VM to an off-site storage system. For better performance, use data de-duplication technology to reduce the amount of time to perform your backup. This system seems to work well, however few providers are offering it.

What do you think? What’s your favourite backup strategy as a hosting company?

We knew it was going to happen but perhaps not so soon. Today Amazon announced that it would be reducing it’s pricing on EC2 linux instances by 15%. That’s a pretty significant cost reduction but we also have to factor in a whole bunch of other costs to figure out what their strategy seems to be.

Unlike with most bundled VPS services where you get a certain amount of disk space, bandwidth, memory and CPU resources, the Amazon model breaks things down into separate categories. You pay per use on everything. Instances per hour, Bandwidth and Storage per Gig, etc. Under this model it makes sense to shift your revenue to things that are higher margin. What that means is that with enough scale, you could almost afford to break even on the server instance and make money on other things – like bandwidth.

This is similar to the concept of “Freemium” in the Web Apps world. You get to use the basic version at a heavy heavy discount (in some cases free), but the add-ons, extra functionality, etc results in having to pay. The difference is that in the harsh reality of hosting, it costs real money to run a server.

There have been quite a few requests on forums and blog posts on a few sites we frequent asking someone to figure out how to move a virtual machine from EC2 to VirtualBox or KVM. We’ve got quite a bit of experience working with KVM so we figured why not try our hand at importing a virtual machine template from the Amazon AMI repository so that developers or sysadmins could run them in their local environments. We’ve already written a howto on importing an AMI from Amazon, so you may want to read that first, but this howto also applies to just creating a KVM or VirtualBox image from a linux filesystem of any kind. Right now this particular method only works with Linux but there are more OS agnostic (and much slower) methods for transposing virtual machines. So without further delay, let’s get started.

You’ll need at least 15 gigs of free space to make this work.

1) Download and unpack an AMI from Amazon

You can learn how to do that here, or if you have sufficient knowledge you can build a full linux filesystem

2) Prepare a new raw drive file

We’ll create a file backed drive, set it up so we can partition it and create a new filesystem.

Create the file by using the ‘dd’ command.

dd if=/dev/zero of=newimage.raw bs=1M count=10240

Add it to a loopback device

losetup -fv newimage.raw

Partition the file backed loopback device. For this we’ll just create one partition which is the whole disk. Make sure its bootable.

cfdisk /dev/loop0

Write the partition and exit

Now we’re going to create a filesystem on the partition we just created. Please note that there’s a problem with the way mfks works. When trying to automatically determine filesystem sizes on loopback devices it makes a mistake. So for this we need to do a few things.

Find the partition beginning, ending, number of blocks, number of cylinders, and blocksize

fdisk -l -u /dev/loop0
 
Disk /dev/loop0: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000
 
      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1   *          63    20964824    10482381   83  Linux

Create a new loopback device for the partition. We do this by calculating the beginning of the partition x blocksize

In this case that’s 512 * 63 (actually in most cases thats what it is)

losetup -fv -o $((512 * 63)) newimage.raw
Loop device is /dev/loop1

Remember those numbers we grabbed earlier using fdisk? Plunk them into this formula. For our example:

( END – START ) x Units / Block Size
If you don’t know the block size use 4096. That’s “standard” and usually the size configured on most ext2/3 filesystems.

So for us it’s this:

echo $(((20964824 - 63) * 512 / 4096 ))

This gives is the number of blocks we need to use in our next command, which is used to create a filesystem with a blocksize of 4096 on /dev/loop1 of block count 2620595. You have to specify the blocksize, otherwise mkfs will try and automatically determine a bunch of things for you which will just break things.

mkfs.ext3 -b 4096 /dev/loop1 2620595

3) Copy & Prepare New Root Filesystem

You can now mount this newly created filesystem somewhere and copy a root filesystem into it. If that filesystem happens to be a Xen image from Amazon, you can use that.

mkdir -p /mnt/loop/1
mount -t ext3 /dev/loop1 /mnt/loop/1
cp -a /some/root/filesystem/* /mnt/loop/1/

Xen virtual machines run with a special kernel that can run under KVM using Xenner, but not other platforms like VirtualBox, so we’re going to copy a real kernel in there. You can use one from another linux system if you want, it will work fine, but you should use one that has the modules required by your virtualization platform. We already have a KVM tuned kernel and initrd available so we’re going to use those.

Note: If you’re going to just copy in the initrd and kernel then make sure the initrd includes all of the modules required to boot your machine.

cp -r /some/boot/filesystem/* /mnt/loop/1/boot/

You should now see a the kernel, initrd and the grub directory in there.

Edit the menu.lst and make sure the root= is set to /dev/sda1

vim /mnt/loop/1/boot/grub/menu.lst

Edit the /etc/fstab in your mounted vm

vim /mnt/loop/1/etc/fstab

Because amazon’s best practices involve setting a random root password, which gets overridden at start time, you’ll have to solve that little problem.

chroot /mnt/loop/1
mv /etc/rc.local /etc/rc.local-old
passwd root
exit

5) Setup Grub on the New Drive

Now unmount /mnt/loop/1 and delete the loopback device for the partition (the one with the offset) so we can setup the bootloader. Grub complains about installing the MBR code when the loopback device is still active on the partition. Leave the loopback device for the entire drive. We’ll need that to get some numbers from fdisk.

umount /mnt/loop/1
losetup -d /mnt/loop1

fdisk -l -u /dev/loop0
 
Disk /dev/loop0: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000
 
Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1   *          63    20964824    10482381   83  Linux

Make a note of the numbers that were presented here. We’ll need the following to setup grub

• Cylinders : 1305
• Heads : 255
• Sectors / Track : 63

These numbers may be different for you depending on the size of partition you created, or a whole bunch of other variables. It’s important to remember these values because we’ll need them for our next step, which is to setup grub.

The following lists the set of commands required to setup the bootloader on a file backed disk over a loopback device.

grub --device-map=/dev/null
device (hd0) /images/newimage.raw
geometry (hd0) 1305 255 63
root (hd0,0)
setup (hd0)

Here’s what that looks like in the grub dialogue:

grub --device-map=/dev/null
 
Probing devices to guess BIOS drives. This may take a long time.
Unknown partition table signature
 
[ Minimal BASH-like line editing is supported.   For
the   first   word,  TAB  lists  possible  command
completions.  Anywhere else TAB lists the possible
completions of a device/filename. ]
grub> device (hd0) /images/newimage.raw
device (hd0) /images/newimage.raw
grub> geometry (hd0) 1305 255 63
geometry (hd0) 1305 255 63
grub> root (hd0,0)
grub> setup (hd0)
 
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  17 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded
Done.
grub>quit

Conclusion

Yay! All you need to do now is delete all those loopback devices attached to your file, and boot it up in either KVM or VirtualBox
Hope you found that useful.