VMware Inc. touts Storage VMotion as a major new feature in ESX Server 3.5, which is only included in the VMware Infrastructure suite. Those familiar with VMotion are halfway to understanding Storage VMotion (SVMotion).
How can VMware's Storage VMotion help you?
VMware's Storage VMotion (SVMotion) goes a step further and allows you to migrate the virtual disk for a guest OS from one data store (disk storage system) to another, while the virtual machine (VM) is running.
Here are some examples of what Storage VMotion allows you to do:
- Move a virtual guest on a local disk from an ESX host to a SAN,
- Move a virtual guest from being stored on one SAN to another,
- Migrate VMs from VMFS2 to VMFS3,
- Have zero downtime when you do SAN maintenance if you have another SAN to migrate the VMs to temporarily and
- Redistribute the load of your SAN across other SANs.
While SVMotion is very cool, there are some downsides to it. The first is that, officially, SVMotion can only be used through the VMware Remote CLI (RCLI). This makes the learning curve for SVMotion painful. The RCLI is not something you can just easily pickup. For example, here is a SVMotion script:
svmotion --datacenter='My DC'
It's disappointing that despite it being such an amazing product, VMware didn't release a GUI interface for SVMotion. However, this is no different from VMware Consolidated Backup (VCB), another excellent and powerful tool with no GUI interface. However, when large companies produce excellent products that lack GUI interfaces, it's always a great opportunity for developers to step in and provide one.
Two options to administering SVMotion with a GUI
Fortunately for VMware administrators there are generous developers out there who have volunteered their time and have created very useable and free GUI interfaces for SVMotion. I have run across two GUI interface options for SVMotion, both of which were introduced at the VMTN VMware community blog:
- Option 1 - SVMotion Windows GUI by Alexander Gaiswinker. This GUI option for SVMotion
is a Windows interface that creates and runs the RCLI scripts for you. With SVMotion Windows
GUI, you install the VMware RCLI, copy the GUI Perl script into the RCLI directory, then run
the exe file.
- Option 2 - SVMotion VI 2.5 Client Plug-in by Andrew Kutz – Andrew Kutz takes a different approach with this plug-in for the VI Client. After installing the plug-in, VMware admins can then right-click on any virtual guest inside their existing VirtualCenter interface and choose to migrate it, and its storage, all in one pass. I have used the VI Client plug-in and can definitely recommend this option. I have not had the opportunity to try out and review Alexander Gaiswinkler's option.
Below are some screen shots of my VI 2.5 client plug-in installation:
You are given a new box (not previously in the VI Client) that asks you where you want to migrate the storage for this VM.
Downloading a third-party GUI interface makes SVMotion much easier to use and it is only a matter of time before VMware comes out with its own or includes one inside the VI Client.
SVMotion raises VMFS disk defragmentation concerns
Let's think about the VMFS for a minute. This is VMware's proprietary file system (called a data store) where all the VMDK virtual disks, your guest OS configuration files, and other critical VMware ESX files are stored. ESX does not support dynamic disks, so when you create a new virtual guest, you create a single VMDK that is large enough to support the needs of the virtual system. Because these VMDKs don't usually grow or shrink, the VMFS is contiguous.
SVMotion, however, enables you to remove a large "chunk" (the large VMDK file for a VM) from one VMFS data store and put it on another data store. If you do so just once, there may not be an issue. But doing this multiple times could create problems.
Consider a scenario in which you move machines back and forth over a period of a year: You start with a 320 GB VMFS partition; 250 GB of it was utilized. Say that you pull a 100 GB disk from the middle of that VMFS partition (you probably wouldn't know where you took it from). Later, you move (via SVMotion) a 50 GB VMDK back into the space that the 100GB was in, leaving 50 GB in the middle of the disk. Then, say you want to move that 100 GB VMDK back to its original location. There is 50 GB in the middle of the disk and 70GB at the end of the disk. In other words, there is not enough contiguous space on the disk.
Since SVMotion lets you move VMDK and fragments it into pieces, the least of your problems would be that the affected server won't perform as well because the file that it's trying to access isn't in a contiguous location. Alternatively, you may not be able to move the VMDK back to its original place at all because there isn't enough contiguous space. In that case, what are your options? Pull off all of the VMDK files and put them back one at a time? Where is the disk defragmentation software for the VMFS? Where are PerfectDisk and Disk Keeper for VMFS?
I do not know all the answers on the disk defragmentation questions. Rather, I am using this example to highlight and bring forth a concern with SVMotion. My point in this article is not to negate it in any way, but to make sure that you are aware of the possible downsides so that you can resolve those and/or be aware of them. Also, I am referring to VMFS defragementation only, and not NTFS, EXT3 or SAN volume degramentation.
ABOUT THE AUTHOR: David Davis (CCIE #9369, VCP, CWNA, MCSE, CISSP, Linux+, CEH) has
been in the IT industry for 15 years. Currently, he manages a group of systems/network
administrators for a privately owned retail company and authors IT-related material in his spare
time. He has written hundreds of articles, six video training courses - including the Train Signal VMware
ESX Server video training series. His websites are HappyRouter.com. and VMware Videos.com.
This was first published in March 2008