SVMotion Usage and Trials
Storage VMotion is a great tool, so I figured I would give it a try in an attempt to get a new SAN into action quickly. It works quite well actually, but does have a few issues still. This migration must run smoothly within my environment as rebooting is just not an option during the day. Just like everyone else I have uptime requirements.
The SAN is a DS3400 attached to two VMware ESX 3.5 Update 2 systems managed by VirtualCenter 2.5 Update 3. So using the latest and greatest toolset I began my endeavors after configuring the SAN. Here are the steps I took:
- Log into the VIC
- Select the VM, right Click and select Migrate storage ...
- Drag the VM from one data store to another
- Click on Apply and Storage VMotion does everything
First I migrated the powered off VMs following this approach. Then the powered on VMs.
Using this method it is possible to move each disk of a VM to other datastores. If you want to keep everything together you need to select the VM not the individual virtual disk.
When I went to the console for the first Windows VM I migrated, it immediately rebooted. Granted the VM had been up for a while, and may have had an update applied. So I migrated another VM, a Linux VM this time. This VM had no issues. Subsequent Windows VMs had no issues.
Unfortunately, this process is one VM at a time to reduce SCSI Reservation Conflicts on the old and new SANs, and that is all the interface allows to happen per request. It would be much nicer to grab a bunch of VMs and dragtheir disks to the new location within the interface and then select apply and it would do them sequentially.Â For lots of VMs, this can get laborious at best. It does work however, and works well.
Note with VMware's version of SVMotion, the RCLI is not required to be available.