Hi folks, this is the 3rd in a series of posts where I talk about NetApp’s involvement with oVirt and RHEV. Previously I talked about how NetApp got involved in the first place, followed up by why NetApp is involved, and today I will conclude with what it is that we’re actually doing.Most, if not all of what I’m going to cover here comes from what I presented at the oVirt Workshop during LinuxCon in San Diego a few weeks ago. As a side note, if you haven’t been to LinuxCon, I highly recommend it. The content, speakers, and activities are all great – not to mention that it’s still a relatively small event (~1000). Anyway, let’s dive into some specific integrations that we’re working on.
The first area of integration is with oVirt-engine/RHEV-M. I’ve talked at length about the importance of offloading storage activities like cloning VMs for rapid deployment. I’ve also talked about streamlining the number of tools necessary to advance through (what should be) simple workflows, such as provisioning new storage. Enter the plug-in framework that is under construction by some of the core oVirt committers. The idea is simple, instead of having to write monolithic applications that have to be recreated with each update, create a plug-in framework that allows API’s to communicate instead.
In our case, we’re creating a plugin that has the following initial goals:
- A NetApp tab – This is exactly what it sounds like. When the NetApp plug-in is installed, it will place a “NetApp” tab in the storage page of oVirt-engine/RHEV-M. This will contain many of the initial and future tools for doing things like discover & manage NetApp controllers, provision new storage (SAN & NAS) right from oVirt/RHEV-M, and eventually auto-configure/confirm storage best practices. We’ve got a ways to go, but work is underway.
- Context Specific Menus – This will allow for context specific actions to be taken. For example, when “right-clicking” on an existing virtual machine there will be the option to “NetApp Clone” the VM, thereby offloading the cloning from the hypervisor to the storage array. A similar action is planned for cloning offload of entire data stores
- Tasks & Workflows – As I mentioned earlier in the post, there’s value in reducing the number of tools necessary to execute a workflow. For example, in order to grow storage for an existing VM datastore, currently you might have to:
- Log into the NetApp Systems Manager tool or NetApp Filer View tool
- Locate the export or LUN that needs to grow (trivial, but still an additional step)
- Walk through a separate workflow to grow the volume or LUN (again it’s trivial, but an additional step)
- Exit the NetApp tool
- Log into the oVirt-engine or RHEV-M
- Go to the the storage tab
- Identify the data store that needs to grow and either confirm the export is bigger, or extend the LUN
Here’s what we’re aiming for:
- Log into oVirt-engine/RHEV-M
- Identify data store that needs to grow
- Right click on the data store, select “Grow NetApp Storage” (or similar)
- Walk through simple workflow (new size, confirm, done)
One tool, one workflow. Let the integration do the heavy lifting. This ultimately means that Senior Engineers/Admins can leave specific change management instructions to others with proper RBAC credentials to handle. It takes less time and there is less room for error. In keeping inline with our other virtualization integrations, this will likely be referred to as the Virtual Storage Console.
The other thing that I’ve covered at Red Hat Summit, LinuxCon, and this blog is the work that we’re doing with “Snap Creator”. Check out some of my earlier posts for a little more in depth explanation, or go to http://snapcreator.com. Snap Creator is a flexible and powerful backup and recovery framework. Essentially, the magic comes from the plug-in architecture as well as the ease of configuring otherwise complicated backup scenarios.
There are several plug-ins available for applications like MySQL, Oracle, and Zimbra. Earlier this year we released a plugin specifically for KVM, and there are plans to create one specifically for oVirt/RHEV. The Snap Creator framework and plugins allow for coordinating the quiescing of applications and virtual machines with NetApp storage for backup, recovery, and a number of other activities.
The plug-ins (both for oVirt/RHEV and Snap Creator) themselves will be open source and you can track progress in the dev lists for oVirt. This isn’t all for the plans, but this is what I can share with all of you for now. I promise to keep things updated as we move forward.
Hope this helps,