This week at Microsoft Ignite 2015 in Chicago, NetApp will demonstrate a new virtual machine conversion product, NetApp® OnCommand® Shift.  OnCommand Shift is fully supported and evolved from our MAT4Shift tool and Shift technologies that have been used by customers and partners for fast VM conversion and hypervisor migration projects.

By using OnCommand Shift, customers can optimize virtualization platform investments, support multihypervisor IT strategies, and remove barriers such as downtime when considering VM migration projects.

OnCommand Shift captures the success with and learning gained from the MAT4Shift tool and takes it to the next level. What does OnCommand Shift do? You, our customers, told us that you love the fact that you can migrate your VMs in minutes with it, with near zero touch! Check! And it does that faster than with MAT4Shift. You also told us that the fact that we use PowerShell rocks! Not only do we use PowerShell, but it’s a true PowerShell module with real CmdLets. So script to your heart’s content. If you want to migrate your VMs in either direction, NetApp can do that too.

OnCommand Shift in action looks like sorcery and magic. Well, it kind of is-NetApp magic! It leverages three unique capabilities that NetApp delivers:

  • NFS and CIFS shares on a single volume
  • The capability to clone files nearly instantaneously regardless of size
  • Conversion of VM disk formats while leveraging the cloning technology for extremely rapid cloning and conversion

Let’s look at how each of these capabilities comes together to make the magic happen.

NFS and CIFS on a Single Volume

Having an NFS datastore mounted on your ESXi server enables you to either create your VMs on that datastore or sVMotion. Once there, the VM is ready to be shifted. With CIFS, your Hyper-V environment can have a place where it can store its VMs or Storage Live Migrate. NetApp’s being able to expose a single volume through both NFS and CIFS allows ESXi and Hyper-V to see each other’s datastores. That leads us to the next piece of magic.

Nearly Instantaneous Cloning of Files

NetApp FlexClone® volumes! FlexClone is your friend. It’s your hero. FlexClone is NetApp cloning technology that allows you to rapidly (almost instantaneously) clone files of any size. How does it work?  Magic! No, not really. It’s just really cool patented technology.

Let me explain. In its simple form, a file (any file) is just a bunch of data blocks stored on the disk. The NetApp WAFL® (Write Anywhere File Layout) system has the capability to “share” blocks of data between different files while maintaining other blocks that make up the files that make them unique. If you look at Figure 1, you’ll notice that the ESXi disk (VMDK) is using five blocks-for simplicity’s sake, A through E. If I were to clone the file, it would appear as though there were two copies of the file of the same size on the disk. In fact, there would be only one, and both files would be using the same blocks with no data duplication. As the two copies of the files started to diverge, WAFL would automatically create new data blocks for the changes. Initially, both files exist on the volume, but they use only the space of one file.

Figure 1) Cloning and Converting VM Disk Files.jpg

VM Disk Format Conversion

The last piece of magic is our OnCommand PowerShell Toolkit. If you haven’t heard about it, where have you been? Look for it. It contains more than 1,400 cmdlets that allow you to perform nearly every action you could possibly imagine on one of our controllers.

Within this toolkit are a few cmdlets that allow you to convert from an ESXi VMDK file format to a Hyper-V VHD or VHDX file format (and vice versa). What we found when writing these cmdlets is that the differences between the VMDK and the VHD/VHDx file formats are pretty minor and that, by leveraging FlexClone technology, we can convert and clone the file at the same time-in a matter of seconds!

Looking back at Figure 1, you’ll notice that the VMDK and the VHDx files are nearly identical; only one block is different in each (blocks E and F). In that example, instead of using 10 blocks, we use only 6. Remember, this is a very simple model; in a real environment, we are talking about thousands of data blocks (the difference between a 40GB VMDK file and a VHDx file is about 1MB).

Putting It All Together

OK, now you know about the magic that makes OnCommand Shift work. But what does it really do under the covers? Simply put, you install OnCommand Shift on a server (either physical or virtual). That server, known as the Shift Server, acts as the orchestrator of the VM migrations. Since we don’t actually copy any files from the NetApp controller, we don’t have to worry about any of the disk data flowing through the server (or the network, for that matter).

The Shift Server performs several actions (as shown in Figure 2):

  • Collects all VM data
  • Takes Snapshot® copies of the VM
  • Removes the hypervisor integration tools
  • Migrates the VM
  • Rehydrates the network 

Figure 2) OnCommand Shift High-Level Workflow.jpg

Let’s look at each of these in a bit more detail.

Collects all VM data

OnCommand Shift connects into the VM guest and collects all the disk and network information. This information is then injected into the VM with a few PowerShell scripts. These scripts are then executed within the guest once it is brought back online on the destination hypervisor. The scripts then rehydrate the network (more on that shortly).

Takes Snapshot copies of the VM

This step coalesces the VM to make sure that we have nice, solid original VM files (the VMDK or VHD/VHDx files). At the same time, our FlexClone technology makes a clone of the original disk file. This becomes our “get out of jail free card.” If anything happens during the conversion or migration process, you have a full backup of the original VM files that can be restored. That enables you to get your original VM back up and running quickly. If something fails, you have a PowerShell cmdlet to restore the original VM.

Removes the hypervisor integration tools

This step is pretty self-explanatory. There’s no need to have the Hyper-V tools on ESXi or the VMware tools on Hyper-V, right? This step simply uninstalls them before you migrate the VM.

Migrates the VM

Now comes the fun part, the actual migration. Several things happen during this step. The first thing we do is shut down the VM on the source hypervisor. For our cloning and conversion magic to work, the VM has to be offline. Once the VM is shut down, we clone and convert the source disk file(s) to the destination format. While doing this, we place the newly converted disk file(s) on the correct datastore.  So if you’re migrating from ESXi to Hyper-V, we clone and convert the file(s) from the NFS datastore to the CIFS share-all in one step.

Once this is done, we create the new VM on the destination hypervisor.  It will have the same name and settings (memory, CPU, disks, and networks) as the source VM. The final step in this section is to power on the VM. At this point the conversion process is complete and OnCommand Shift can move on to the next VM in the conversion queue. Did I forget to mention that you can queue up a bunch of conversions? You can!

Rehydrates the network

Remember that we injected the guest VM with the original configuration and some PowerShell scripts? This is where they come in. When the VM first starts up, we auto-logon and execute the rehydration scripts. Those scripts reconfigure the disks and networks so that they are identical to what they were before the migration. So if you have custom network adapter names or static addresses, no worries. You’re covered-we take care of that for you automatically.

Once the scripts complete executing, we perform a final reboot and the migration is done. Simply log into the server and confirm that it is running as you’d expect it to. Cool, huh?

PowerShell, PowerShell, PowerShell

What can I say? PowerShell is your friend. The interface for OnCommand Shift is a set of PowerShell cmdlets. Using these cmdlets you can:

  • Connect to the Shift Server
  • Configure:
    • The guest credentials
    • The ESXi and Hyper-V hypervisors
    • The network mappings
    • The NetApp controller settings
  • View:
    • The job status
    • The migration report
  • Migrate a virtual machine
  • Restore a failed migration

With these cmdlets you can use your favorite workflow automation tool to automate VM migrations. Would you like to sVMotion or Storage Live Migrate the VM before the migration? PowerShell can do that. Would you like to add the VM to your Hyper-V failover cluster? PowerShell can do that too!

Final Thoughts

So there you have it-NetApp magic! However, although we are announcing at Ignite, the OnCommand Shift product has not shipped yet. How long do you have to wait to try out this VM migration product? Not long, just a few weeks. Look for its release on the NetApp Support site.

When it’s available, download it, install it, try it out, and let us know what you think.

For more information, go to the OnCommand Shift product page here.

Check out what else NetApp is showcasing at Microsoft Ignite:

BarryShilmover