Welcome to the inaugural edition of Boxes of Boxes, a bi-monthly virtualization, containerization, and turduckenization column. Given the title and subject matter of this column, and the fact that version 3.14 of GNOME desktop environment has recently shipped, I decided to take a look at the project’s built-in application for running virtual machines: GNOME Boxes. I took GNOME Boxes for a spin on Fedora 21 alpha, which also shipped recently, sporting GNOME 3.14 as its default desktop environment.
The GNOME 3.14 release notes point to support for Debian as a newly added “express installation” target for GNOME Boxes, so I started off by pointing the app at a Debian Wheezy installation ISO I’d downloaded. The express installation feature suggests a set of sane defaults for virtual disk size and for VM memory, asks for a password, and promptly chefs up a fresh VM instance, and the feature worked as expected with the installation I’d kicked off.
Dockermania has been running wild, and it seems as though there’s an advocate for swapping in the containerization technology wherever we once turned to virtual machines. While Docker won’t (yet) fit the bill in all of these cases, containers are great for trying out new or updated Web applications on your local machine.
When compared to dynamic sites based on WordPress or Drupal, staticly generated blog and Web sites (like this one) can go a long way toward simplifying deployment and maintenance. There’s no database or server-side code to maintain, and, when paired with a service like Github or Gitlab, you can accept posts or other contributions from anyone, via pull request.
However, while simplifying certain areas, static sites introduce a bit more complexity in other areas. Among the handful of Middleman-based static sites that our team at Red Hat help maintain, we’ve seen the specter of “it works on my laptop” arise.
When Project Atomic got off the ground in April, I wrote a blog post about how anyone could Build Your Own Atomic host, based on Fedora 20. Since that time, there have been some changes in the rpm-ostree tooling used to produce these images.
What’s more, there’s a new distro on the block, CentOS 7, that you may wish to build into an Atomic host. Part of what’s great about the Atomic model is the way it can apply to different distributions. Here’s our chance to play with that.
oVirt’s Hosted Engine feature, introduced in the project’s 3.4 release, enables the open source virtualization system to host its own management server, which means one fewer required machine, and more self-sufficiency for your oVirt installation.
While a self-sufficient oVirt installation has been achievable for some time using the project’s “All-in-One” method of running an oVirt virtualization host and management server together on one machine, the Hosted Engine feature allows multiple machines to partake in the hosting duties, eliminating any one host as a single point of failure.
The Hosted Engine feature relies on NFS storage to house the management VM. Running an NFS server on one of our virtualization hosts would make that host a new single point of failure, which means we need either to tap an external NFS filer (the approach I took in the walkthrough I posted here recently) or we need to figure out how to make our oVirt hosts serve up their own, replicated NFS storage.
In this post, I’m going to walk through that latter option – setting up a pair of CentOS 6 machines to serve as oVirt virtualization hosts that together provide the NFS storage required for the Hosted Engine feature, using Gluster for this replicated storage and for NFS and CTDB to provide a virtual IP address mount point for the storage.
The application as shipping container metaphor behind the Docker project’s name and logo paints an attractive picture for developers: spawn a container on your local machine, fill it with code, and then ship it off to your far-flung users.
While the app is where the action happens, I can’t help but wonder what sort of ships await our containers when they arrive at the dock. No matter how well you’ve crafted or carefully you’ve packed your cargo, your application will only make it as far as its ship can take it.
Maybe the best thing about Project Atomic is the way it addressess both the shipping container and the ship itself, the former with Docker, and the latter with an intriguing (if less catchily-named) project called rpm-ostree.
We can use rpm-ostree to take a set of packages from one of our friendly neighborhood RPM-based Linux distributions, assemble it into a “just-enough” OS image, and then deploy and manage hosts based on that image in a manner that more closely matches the container model than do traditional OSes.
Last week, the oVirt Project delivered a new version of its open source virtualization management system, complete with a feature I’ve eagerly awaited for the past two years. The feature, called Hosted Engine, enables oVirt admins to host the system’s management server (aka the engine) on one of the virtualization hosts it manages.
While oVirt was designed to run across separate management and virtualization hosts, it’s been possible from early on (version 3.0) to hack up a machine to serve both roles. In subsequent releases, the project approved and refined this installation option into an easy-to-use All-in-One (AIO) installation plugin.
The problem with AIO is that it leaves you with one of your most important workloads (the oVirt engine) stuck running on a single piece of hardware, where it can’t easily be moved around – a very un-virt scenario. Hosted Engine gives those of us interested in getting oVirt rolling on a single server a new deployment option, and one that promises to scale out more nicely than possible with the AIO plugin.
In this post, I’m going to walk through the installation and first steps of a basic oVirt install using the Hosted Engine feature.
The CentOS Project is increasing its efforts to empower contributors to produce and collaborate on new CentOS Variants, in which groups of contributors combine the CentOS core with newer or otherwise custom components to suit that group’s needs.
Xen4CentOS, which combines CentOS 6 with components from the Xen project and the “longterm maintenance” release of the Linux kernel, is an example of an existing variant project. For more on variants, refer to the CentOS Project site and the CentOS and Variants section of our FAQ.
The contributor groups behind variants are called Special Interest Groups. For more on SIGs, refer to the CentOS Project wiki.
The All-in-One install I detailed in Up and Running with oVirt 3.3 includes everything you need to run virtual machines and get a feel for what oVirt can do, but the downside of the local storage domain type is that it limits you to that single All in One (AIO) node.
You can shift your AIO install to a shared storage configuration to invite additional nodes to the party, and oVirt has supported the usual shared storage suspects such as NFS and iSCSI since the beginning.
New in oVirt 3.3, however, is a storage domain type for GlusterFS that takes advantage of Gluster’s new libgfapi feature to boost performance compared to FUSE or NFS-based methods of accessing Gluster storage with oVirt.
With a GlusterFS data center in oVirt, you can distribute your storage resources right alongside your compute resources. As a new feature, GlusterFS domain support is rougher around the edges than more established parts of oVirt, but once you get it up and running, it’s worth the trouble.
The oVirt Project is now putting the finishing touches on version 3.3 of its KVM-based virtualization management platform. The release will be feature-packed, including expanded support for Gluster storage, new integration points for OpenStack’s Neutron networking and Glance image services, and a raft of new extensibility and usability upgrades.
oVirt 3.3 also sports an overhauled All-in-One (AIO) setup plugin, which makes it easy to get up and running with oVirt on a single machine to see what oVirt can do for you.