h0bbel.p0ggel.org

Back in August 2006 the Gallery team released version 1.0 of The Gallery Appliance and a new and improved version was released last Friday. The new release includes several improvements:

• 1. Updated Gallery 1 and Gallery 2 versions
  The new version includes Gallery 1.5.6 and Gallery 2.2.1
• 2. More Gallery 2 modules enabled, and Downloadable Plugins are also available.
• 3. SCSI emulation instead of IDE emulation makes it possible to run on VMWare ESX server.
  There is an VMware ESX image for those who want to run it on VI3.
• 4. rPath Appliance Platform (rAP) agent for remote appliance administration
  This is interesting. The people over at rPath has created a remote administration agent for appliances built on their rPath Builder service. It helps end users schedule backups, manage the appliance and makes updating to newer releases easier.
• 5. Increased number of build types.
  The appliance is now available in 9 build types, ranging from VMware and Microsoft VHD via Xen and Amazon e2 (ami-468c692f) to bootable cd based installs.

Now, where does the nice people come into it? Well, without the great help and drive from Valentyn Khokhlov and Michael K. Johnson of rPath this release would not have happened when it did. The first incarnation of the appliance was hacked together by Donald Webster, also known as fryfrog, and maintenance and upgrades were not first on the priority list. This time rPath approached us, asking if we were interested in updating the appliance now that new Gallery versions had been released. Of course we were interested, but lack of time and especially lack of rPath/Conary know-how limited us. Michael and Valentyn stepped up and pretty much rebuilt the whole appliance for us, while I kept the role as the nagging nitpick.

Hopefully we'll be able to do the heavy lifting ourselves when we update the appliance next time, and I really hope we don't need to rely on the goodwill of others to get it done properly.

Again, a big thank you goes out to rPath who helped us immensely this time around, they really did us a great favor!

So far the appliance has been downloaded over 300 times since friday, and feedback is starting to make it's way back to us. If you have tested it, please provide any feedback you might have in the Gallery Appliance forums and leave a comment here as well.

I'm very happy with this, and I hope we can make the next version even better.

The Gallery Appliance has been hightlighted on the rPath site, and is now listed as #1 under the Recommended Appliances list. Other hightlighted appliances include SugarCRM, MediaWiki and Asterix, a list that really puts Gallery alongside some pretty neat projects.

Nice to see the appliance getting some PR again, now just wait and see what's in stock for Gallery 2.2. It's shaping up as a great release, with some really nice additions already present in the codebase. More details about that later.

As we all know, pre-setup Virtual Appliances is an excellent way of testing and evaluating applications and setting up lab environments. Utilizing the same technology as a distribution method also has lot of additional advantages over traditional software distribution:

Reduced complexity

The end user doesn't have to set up complex dependencies and wrestle with software versions and incompatibilities.

Better optimization

The software is alread configured by the people who knows it best. Download and run functionality that leaves the end users with the task of actually testing the software, not testing the installation routine. If done correctly, Virtual Appliances are mean, lean, virtual machines.

Cross Platform

Until Microsoft does something regarding their licensing terms, using Windows as a base for a Virtual appliance is pretty much out of the question. Virtual Appliances could, however, be used to give Windows users access to Linux applications, without the need to install Linux on their computers.

Better resource utilization

End the one app, one box race. In theory you can multiple applications on one server, but normally you end up running dedicated servers for dedicated applications. By using Virtual Appliances, you can combinine multiple appliances on one physical box. With the growing concern regarding server power consumption, combining servers into fewer physical boxes makes a lot of sense. Power consumption is reduced, and computer resources more efficiently utilized as most standalone servers today are rarely utilized to their maximum potential. This leads to less power usage for the actual servers and subsequently less heat generation which in turn reduces the need for cooling. Cramming Virtual Appliances into less physical boxes, also reduces the need for space.

Increased portability

Since the hardware is virtualized, Virtual Appliances are portable. Get some generic hardware installed, run the virtualization engine installer and start the Virtual Appliance. Thats an advantage the hardware appliances just don't have.

A typical hardware appliance would be a firewall, right? Now, if your firewall decides it's time to leave the planet and give up, what do you do? You have to replace the physical box with a new one, in most cases an identical one. Normal procedure would then be to get it configured with the correct network settings and then restore the policy set from backup (Unless you have the whole config saved somewhere and dump it to directly to the new box). This will take some time, and you might not even be able to get a new firewall delivered the same day.

Now imagine the same scenario with a Virtual Appliance firewall. The hardware that runs the firewall crashes, what do you do? You have a few choices here. Since the Virtual Appliance runs on some generic hardware, you can probably replace the faulty hardware on your own. How often can you do actual hardware maintenance on a hardware appliance?

If thats not possible and you need to get up and running again fast, you install the virtualization layer (VMware Player/Server) on anther computer and boot the appliance from there (after all, you do have backups right?). My point is quite simple, it's much easier to get up and running again quickly if you base your infrastructure on virtual appliances instead of hardware ones.

Price

Running virtual appliances can be dirt cheap. Get some decent hardware (ram is important!), stick a few network cards in it and some storage and you have a nearly instant firewall/webserver/mailserver/storage server big enough to run a small office. If you run VMware Server on Linux you could end up only having to pay for the hardware itself. The rest is available for free (and yes, like in beer).

Building your own appliances

Most Open Source development teams are built around volunteers and passionate developers and users, like Gallery. This also means that most projects like this doesn't have the means to get a custom hardware appliance built nor any interest in doing so. By creating the Official Gallery Appliance we could distribute a pre-configured Gallery Appliance, without having to deal with the hardware.

Thanks to the people over at rPath we were able to build and distribute a fully fledged Gallery install, certain to work just about everywhere! I'm sure more services like this will become available in the future, Moka5 springs to mind.

Future of Virtualization

We'll just have to wait and see where we end up with this whole virtualization craze. Some people has really started to think big about the future of virtualization and what we might have in store. Intriguing thoughts, and perhaps Gartnes is correct and Microsoft Vista will be the last monolithic OS from Redmond after all?