We’re about one week away from the release of oVirt 3.1, and I’m getting geared up by sifting through the current Release Notes Draft, in search of what’s working, what still needs work, and why one might get excited about installing or updating to the new version.
Web Admin
In version 3.1, oVirt’s web admin console has picked up a few handy refinements, starting with new “guide me” buttons and dialogs sprinkled through the interface. For example, when you create a new VM through the web console, oVirt doesn’t automatically add a virtual disk or network adapter to your VM. You add these elements through a secondary settings pane, which can be easy to overlook, particularly when you’re getting started with oVirt. In 3.1, there’s now a “guide me” window that suggests adding the nic and disk, with buttons to press to direct you to the right places. These “guide me” elements work similarly elsewhere in the web admin console, for instance, directing users to the next right actions after creating a new cluster or adding a new host.
Storage
Several of the enhancements in oVirt 3.1 involve the project’s handling of storage. This version adds support for NFSv4 (oVirt 3.0 only supported NFSv3), and the option of connecting external iSCSI or FibreChannel LUNs directly to your VMs (as opposed to connecting only to disks in your data or iso domains.
oVirt 3.1 also introduces a slick new admin console for creating and managing Gluster volumes, and support for hot-pluggable disks (as well as hot pluggable nics). With the Gluster and hotplug features, I’ve had mixed success during my tests so far–there appear to be wrinkles left to iron out among the component stacks that power these features.
Installer
One of the 3.1 features that most caught my eye is proof-of-concept support for setting up a whole oVirt 3.1 install on a single server. The feature, which is packaged up as “ovirt-engine-setup-plugin-allinone” adds the option to configure your oVirt engine machine as a virtualization host during the engine-setup process. In my tests, I’ve had mixed success with this option during the engine-setup process–sometimes, the local host configuration part of the setup fails out on me.
Even when the engine-setup step hasn’t worked for me, I’ve had no trouble adding my ovirt-engine machine as a host by clicking the “Hosts” tab in the web admin console, choosing the menu option “New,” and filling out information in the dialog box that appears. All the Ethernet bridge fiddling required from 3.0 (see my previous howto) is now handled automatically, and it’s easy to tap the local storage on your engine/host machine through the “Configure Local Storage” menu item under “Hosts.”
Another new installer enhancement offers users the option of tapping a remote postgres database server for storing oVirt configuration data, in addition to the locally-hosted postgres default.
oVirt 3.1 now installs with an HTTP/HTTPS proxy that makes oVirt engine (the project’s management server) accessible on ports 80/443, versus the 8080/8443 arrangement that was the default in 3.0. This indeed works, though I found that oVirt’s proxy prevented me from running FreeIPA on the same server that hosts the engine. Not the end of the world, but engine+identity provider on the same machine seemed like a good combo to me.
Along similar lines, oVirt 3.1 adds support for Red Hat Directory Server and IBM Tivoli Directory Server as identity providers, neither of which I’ve tested so far. I’m interested to see if the 389 directory server (the upstream for RHDS) will be supported as well.