Thanks for checking out my first new “real” post in quite some time. I’ve been neck deep in OpenStack since I got back from Red Hat Summit and I’ve barely had time to come up for air. I’d like to help announce the release of oVirt 3.3, that came out on the 16th (I’m only 4 days late in talking about it!!). There are a number of new features added and I’m going to highlight my 4 favorites below.
Before I dive into my favorite new features, I want to briefly remind folks why oVirt is important. First and foremost, it is the only fully open source end-to-end virtualization platform. It builds a real and viable ecosystem for KVM, and it represents choice in the data center. Additionally, it provides everyone a transparent view into the very active roadmap for Red Hat Enterprise Virtualization.
Ok, let’s move onto my favorite features. In no particular order:
- Neutron integration – Neutron is the new name for Quantum network provider; the same one used in OpenStack (hint, hint). I like this because it provides real network capabilities beyond the Linux bridge utility. The Linux bridge utility’s biggest strength has also been it’s biggest detractor: simplicity. It’s insanely easy to setup, but that’s only because you can’t do much with it. On the other hand, Neutron allows for folks to take their favorite network plugins such as Open vSwitch, Cisco Nexus, the venerable Linux bridge, (and many others!) and use them with oVirt. Between Neutron and the plugins, you can add in things like QoS, VLANs, L2-L3 tunneling and many other necessary tools. It also helps in the convergence of a traditional virtualization platform and OpenStack.
- Migration network – This may sound like a “so what?”, but it’s not. This is actually very important, depending on the size of your virtualization environment and how many VMs you’re supporting. For the sake of argument, let’s say you’re running 200 VMs on 20 nodes of various sizes. If you’ve got your power saving thresholds and/or load balancing thresholds setup, you could actually flood your management network with migration traffic. This allows you to separate the migration traffic onto it’s own network or VLAN.
- Disk Block Alignment Tool – If you go back to my very first post on this blog, you’ll see that I opened this blog with an article on the importance of proper file system alignment in virtual environments. We’ve seen as much as a 40% degradation in performance for mis-aligned filesystems. It’s an easy problem to avoid, it’s a difficult problem to fix after the fact. The good new is that it’s not an issue for RHEL starting with v6 (and I think Fedora 13, but don’t quote me), or for M$ operating systems starting in 2003 and beyond. Anyway, this tool allows you to view and fix mis-aligned filesystems for those legacy apps that you’re forced to run on RHEL 3, Centos 4, Fedora 5, or M$ 2k… (I don’t envy you if you match any of those OS’s)
- Self-Hosted Engine – this might actually be my favorite new feature. If you’ve read any of my Technical Reports on deploying RHEV with NetApp, I first applaud you for staying awake!!! Secondly, you will see a pattern of deploying RHEV-H and thick hypervisors on one side of an imaginary fence, and deploying the RHEV-M (oVirt Engine) and other management apps as VMs on RHEL 6 hypervisors on the other side. This allows for a “control plane” and a “compute plane”. But mostly it provides the ability to migrate RHEV-M (think oVirt Engine) from node to node for all the reasons that you would want to virtualize an application in the first place. The Self-Hosted Engine capability makes that separate control plane obsolete, and I’m fine with that. It allows for a much cleaner architecture. Instead of the control plane being a physically separate entity, it’s simply in a different RHEV (oVirt) cluster.
For more information on all of the new features, including deep dives I highly recommend a visit to: http://www.ovirt.org/OVirt_3.3_release_notes.
hope this helps,