What a great tool Storage VMotion is. I may not use it every day, but when certain situations arise I really appreciate having this feature available.
The other night our storage area network (SAN) admininstrators shut down both of our SANs so they could do a microcode upgrade. Part of this process involved shutting down all of our production virtual machines (VMs) that were on shared storage before the SAN was shut down.
But there are certain servers that you want to have available at all times. In my work this includes at least one DNS and Active Directory server as well as our VPN authentication server. Because these VMs are all on shared storage I decided to use Storage VMotion to move them temporarily to local storage so they would be available while the SAN was down. With Storage VMotion I was able to do this while all the VMs were powered on with no interruption to service.
What Storage VMotion is and how it works
Introduced with VMware ESX 3.5 and vCenter Server 2.5, Storage VMotion allows you to move VMs from one storage data store to another while the VM is running. The difference between VMotion and Storage VMotion is that VMotion simply moves a VM from one ESX host to another but keeps the storage location of the VM the same; Storage VMotion changes the storage location of the virtual machine while it is running and moves it to another data store on the same ESX host. The source and destination data stores can include any storage volume that is configured on an ESX host, which includes local and shared storage. The magic behind Storage VMotion involves several behind-the-scenes steps, which are outlined below:
- A new virtual machine directory is created on the target data store, virtual machine configuration files and all non-virtual disk files are copied to the new target directory.
- The VMware ESX host does a “self” VMotion to the target directory.
- A snapshot (without memory) is taken of the virtual machine’s disks in the source directory.
- Virtual machine disk files are copied to the target directory.
- Snapshot that is located in the source directory is consolidated into the virtual machine disk files located in the target directory.
- Source disk files and directory are deleted.
With ESX 3.5 you either had to initiate a Storage VMotion using a Remote Command Line Interface (Remote CLI) Perl script, or you could use a third-party plug-in developed by Andrew Kutz to do this inside the VMware Infrastructure Client. Storage VMotion is now fully integrated into the vSphere Client but you can still use the Remote CLI as well.
To be able to use Storage VMotion there are a few requirements that must be met, as outlined below.
- Virtual machine disks must be in persistent mode or be a raw device mapping (RDM) that is in virtual compatibility mode.
- If a virtual machine has any snapshots then it cannot be migrated, you must delete them before you can proceed.
- The ESX host that the VM is running on must be licensed for VMotion and must also be configured to use VMotion.
- The ESX host that the VM is running on must have access to the source and target data stores.
- The ESX host that the VM is running on must have enough resources available to support two instances of the virtual machine running at the same time.
It’s not every day that you will use Storage VMotion, but it can come in very handy in certain situations when a VM needs to be moved to another data store and you can’t afford to shut it down.
You can also use Storage VMotion and VMotion together to move a VM from a local data store on one host to a local data store on another host by first using Storage VMotion to move it to shared storage, then using VMotion to move it to another host, and finally using Storage VMotion again to move it back to local storage on the new host.