oVirt 3.1 is Live and Kicking!

Yesterday, oVirt 3.1 was released and touts a number of new features and capabilities. When you’re done reading this quick article you can read about the rest here. There really is a bunch of great stuff. BUT, what I would like to focus on today is the “all-in-one” installation. The all-in-one, or single machine installation, allows for all of the tools and capabilities to be deployed on a single host.

Two words: rapid testing

Instead of having to deploy the management piece (ovirt-engine) on one host and the hypervisor (ovirt-node) on another, all ingredients are dropped in the same pot and stirred. I can’t wait to put this in my lab. Here’s how I see using it:

  1. Deploy Fedora 17 (Beefy Miracle!), booting from SAN
  2. Grab the all in one package and install
  3. Clone the boot LUN and set that clone aside (now my all-in-one template)
  4. Test new feature(s) in oVirt, break and/or test pending integrations (open bugzillas as necessary)
  5. Figure out what went wrong
  6. Delete the broken deployment
  7. Clone my template then wash, rinse, repeat.

Why the excitement? Because while I love the testing, the breaking, the writing, and the integration I really don’t like the setup and resetup (is that a word?) time associated with maintaining a lab. I’ve never been one for “care and maintenance”, preferring “new toys and what’s next?”. Setup time is time lost to me. And while I’ve long been able to clone or otherwise automate things prior to this, the single machine install will cut down setup/resetup time significantly.

Jason Brooks (@jasonbrooks) created a great little video that I’ll highlight now that highlights how to deploy the single machine installation:

So that’s my immediate take on the single machine install and hopefully that helps you as well. But I’d really love to know how you see using it, or even oVirt in general.

thanks for reading,

Captain KVM

3 thoughts on “oVirt 3.1 is Live and Kicking!”

    1. Hi Toni,

      You can in fact run ovirt manager as a KVM guest. I would recommend that you keep that hypervisor separate from the ‘production’ VMs, though. For example, if you have 10 hypervisors that run all of your important VMs, maintain 2 more hypervisors for your ‘infrastructure’. The infrastructure VMs could be running ovirt-engine, a provisioning server, an authentication server, and/or package repo’s. This provides your management pieces with the same flexibility as your production VMs.

      hope this helps,

      Captain KVM

Agree? Disagree? Something to add to the conversation?