Has anyone used 'Storage Vmotion' to move VM's from one data store to another? From what i understand it can be done live.
I don't know if attachments work across the user group, so I cut and pasted just in case from the RTFM site.
Also here's the link to the PDF, it has a great write up on Storage VMotion.
http://www.rtfm-ed.co.uk/?page_id=7
Good Luck,
Chris Reynolds
IT Director
KSAT-12 TV
office: (210) 351-1200
cell: (210) 219-7051
e-mail creynolds@ksat.com
Storage VMotion
Note:
At the time of writing this document I had some difficulty getting Storage VMotion working noninteractively.
It threw up a number of internal errors. However after some effort I was able to
make the non-interactive method work. This said an “interactive” Storage VMotion from the
command-line was always successful and easy to follow.
Storage VMotion is a new feature which you may have already used in the migration process from
ESX 2.x.x to ESX 3.0.1. Since ESX 3.0.1 we have been able to move running ESX 2.x.x VMs from
VMFS2 to VMFS3 volumes. The feature back then had a community name of “DMotion” and was
intended to offer zero downtime for upgrades. This term “DMotion” is not an official VMware
term, but comes from the fact that the delta files created during the VMotion process have name
“DMotion” in them.
This feature has been extended to allow the movement not of a VM from one ESX host to
another, but from one datastore to another – in fact the VM is kept on the same ESX host while
the VMs are “moved” to another datastore. Storage VMotion can relocate the entire VM, or just
individual virtual disks using the –-disk option. The advantages of Storage VMotion are many and
include:
• Free up space in VMFS volumes that are full or part of a general storage/LUN
reconfiguration
• Cope with future upgrades where the VMware File Systen has changed
• Disk Performance optimization by re-blending VMs to reduce disk contention
• Solve disk location problems where users have created VMs on local storage rather than
shared storage
Storage VMotion has some key requirements and limitations. Right now the feature is only
available from the Remote CLI although VirtualCenter already has the option to move a VMs files
during using the cold-migration wizard. VMware do plan for the feature to be integrated in
VirtualCenter in future releases. We hope this will be the case once VI-3.5 has become GA.
As with VMotion there are virtual machine and ESX host restrictions. This list is quite extensive
• Virtual machines with snapshots cannot be migrated
• Virtual machine disks must be in persistent mode or be RDM’s
• The host on which the virtual machine is running must have sufficient resources to support
two instances of the virtual machine running concurrently for a brief time.
• Only one migration can occur per datastore at any one time
• The host on which the virtual machine is running must have access to both the source and
target datastores.
• VMotion must be setup and licenced the host
• You can’t move a VM with NPIV enabled
• You can’t VMotion whilst performing a Storage VMotion
• If you have a VM with more than one VMDK stored on different VMFS volumes – and you
move it without using the “—disks” option – it will take all the VMDKs and put them in a
single VMFS volume
The reasons behind these restrictions are obvious once you know how Storage VMotion works.
Firstly, the VM cannot have snapshot currently applied to it, this is because the Storage VMotion
feature uses snapshots to “unlock” the files of the VM thus allowing them to be “moved” to
another VMFS volume. Secondly, the ESX host needs free memory and CPU resources of the
same amount as the VM being relocated – this is sometimes referred to as “self-VMotion” by
VMware. The internal Storage VMotion creates a hidden copy of the VM which is similar to the
hidden VM used within VMotion. This allows a seamless switch over to the VM which has been
duplicated in a different storage location from the original VM on the original storage location. For
this reason the requirements of VMotion extended to Storage VMotion – for example VMotion
must be enabled and licensed.
The Remote CLI utility “svmotion.pl” can be used interactively (it prompts you for the required
options) or non-interactively. It’s worth using the utility interactively once to become familiar with
the required variables before using the tool straight at the command-line with switches. Before
you begin the Storage VMotion you will need to know the path to the VMX file. This is not
specified as you would at the Service Console (for example:
/vmfs/volumes/virtualmachines/vm1/vm1.vmx) but in a syntax you see only in VirtualCenter
which looks like this:
You will find this syntax when if choose to Edit Settings of a VM, and select the Options Tab under
“General Options”. Figure C.70 shows the information required
Figure C.70
Storage VMotion - Interactively
Warning:
svmotion.pl like other command-line tools is case-sensitive. This includes passwords; datacenter
names; the path to the VMX file; destination datastore
1. Open a CMD prompt on the system you have installed the Remote CLI
2. Type the command:
svmotion.pl –-interactive
Note:
The CLI will then print the response
Entering interactive mode. All other options and environment variables will be ignored
3. Next provide the name or IP address of the VirtualCenter server
Enter the VirtualCenter service burl you wish to connect to
(e.g. https://myvc.mycorp.com/sdk, or just myvc.mycorp.com): virtualcenter.VI-
3book.com
4. Next provide your username and password to connect to VirtualCenter
Enter your username: administrator
Enter your password: vmware
Note:
VMotion will then respond with the message:
Attempting to connect to https://virtualcenter.VI-3book.com/sdk.
Connected to server.
5. Next type the name of the datacenter
Enter the name of the datacenter: London DataCenter
Note:
You do not need to provide speech marks represent spaces, but VMotion is case-sensitive
hence the capital L and D and C in London DataCenter in my example
6. Using the syntax found on the settings of the VM, provide the path to the VMX file
Enter the datastore path of the virtual machine (e.g. myvm/myvm.vmx):
7. Supply the name of the destination datastore, in my case the VMFS volume is labeled
virtualmachines
Enter the name of the destination datastore: virtualmachines
Note:
You do not have type in square
8. If you wish to move the entire virtual machine to a different location, then choose No, to
the question about moving just the virtual disk
You can also move disks independently of the virtual machine. If you want the disks to
stay with the virtual machine, then skip this step..
Would you like to individually place the disks (yes/no)? no
After confirming this last question, you will then see progress bars, as the VM is moved
from one VMFS volume to another
Performing Storage VMotion.
0% |
Wow thanks Chris for the info. There are a lot of dependencies there. And I didn't clarify when I asked the question, but in reading the text in your response I did see something that may shoot down what we are attempting to do. What we are attempting to do is Storage Vmotion VM's from another City to SA or vice versa. So the host will not have connection to the storage in the remote location and this is what we are attempting to accomplish. I believe that from VM we understood that this could be done and what we were looking for was someone who had done it here locally so we could gain from their knowledge.
I haven't done it before, but I think you need an insane amount of bandwidth and a kick ass service level from your ISP. Because wouldn't that make your remote site dependent on that internet pipe for day to day operations?
Thread moved to a more appropiate forum to acheive a better audience
Tom Howarth
VMware Communities User Moderator
http://communities.vmware.com/thread/126141
i've been using this plugin and it works really well. Of Course I have not tried it across a WAN link.
Basically what I believe happens is:
vmx file snapshot location is changed to point to new storage location.
snapshot is taken, which puts the VM snapshot on the new storage location.
vmkfstool is run against the now frozen disk file to move it to the new location
vmx is updated with the new disk location path
snapshot is deleted (which applies it to the disk which is in the new location.
vm has now been svmotioned ot the new storage..