In the previous posts I showed how valuable the ability to offload cloning from the KVM hypervisor to the backend storage could be. Specifically, I was using NetApp FlexClone to create new VM’s for use on a RHEL 6 (KVM) hypervisor. The VM creation time was literally cut from minutes to seconds.
So, what about RHEV?
(Wasn’t that a song by “Heart” in the mid-80’s?)
The truth is that FlexClone and RHEV are hardly BFF’s at this point. That’s one of the things that makes the following demo cool. That and the fact that we create a fully functioning VM in 11 seconds. But I’m getting ahead of myself. The easiest way to explain the disconnect between 2 technologies (that by all accounts should be soul mates) is this: in the case of RHEL+KVM, all we needed to do post-clone was to use the `virsh define new_vm.xml` command in order to make “libvirt” aware of the new virtual machine. In the context of RHEV, we can still clone the VM’s at will, we just don’t have any way to make RHEV aware of the newly created VM’s.
Enter “oVirt”. For the unitiated, oVirt is short for “Open Virtualization”, and is the upstream project for Red Hat Enterprise Virtualization (RHEV) and the KVM ecosystem. Think of it this way: Fedora Linux is free (as in beer), free (as in open source), and where Red Hat does all of their RHEL development. oVirt has the same relationship with RHEV. The difference is that the oVirt board has representation from not only Red Hat employees, but also IBM, Cisco, NetApp (me), and others. (go visit http://ovirt.org for more information and to download oVirt.)
The point of oVirt is to create a virtualization platform based on open source, collaboration, open standards, and integration. That’s the 3rd thing that makes the demo below so darn cool; 2 developers that I work with (Dustin & Ricky) hacked VDSM (the part of RHEV/oVirt that deals with storage) to send cloning requests to the NetApp controller, instead of using its own native code. And while the final code that will ultimately get submitted upstream to oVirt will most likely be different from what is used in the demo below, the point is that we’re working on it and have made significant progress. So while FlexClone and RHEV aren’t soul mates yet, we’ve officially introduced the 2 of them.
Here’s a quick run through of what you’re about to see, unless of course you’ve skipped everything that I’ve typed above in order to jump to the demo. Can’t say I blame you. But just in case:
- We log into an instance of RHEV-M
- Create a new VM based on a template (RHEV uses the `dd` tool under the covers to clone the template VM)
- We wait approximately 12 minutes for the operation to complete (actually, I trimmed out the boring stuff)
- Then we switch to an instance of the oVirt manager
- We create a new VM based on a template but we’ve switched part of the VDSM code to send the clone request to the NetApp controller instead of a local `dd`
- We watch the open NetApp console with baited breath
- BOOM! We have a new VM in 11 seconds, and RHEV is ready to use the new VM
[FMP width=”640″ height=”360″]http://captainkvm.com/wp-content/uploads/2012/07/oVirt_FlexClone5.mp4[/FMP]
I was fortunate enough to show this to a large, interested crowd this past week at the end of one of my sessions at Red Hat Summit. And one of the first questions was “when will this be officially supported?” – The short answer is that we’re targeting the 3.2 release of RHEV, which ~should~ be out in the 1st half of 2013.
So, integrating a rapid cloning tool into RHEV is very cool.. But what about integrated data protection for my virtualized application data? Hmmmm… great question.. (stay tuned.)
hope you liked this,