So, I'm in the process of getting all my various Veeam Backup jobs scheduled. I've got several different jobs for several different types of servers – Windows, Linux, Apps/SQL, Email, Files, etc. I'm separating them because of different requirements on the "restore" piece. Anyway, as I'm working on this, I've noticed that several of my VMWare ESX Datastores are REALLY full. This is because I made a mistake – when I was building these a couple years ago, I did not accurately plan for snapshots. I was going to do the snapshotting on the SAN instead of inside ESX. But, Veeam does ESX-based snapshots for the backups. So… I need to increase the size of my ESX Datastores – on some of them.
Good news! There's a feature on ESX 3.5 called "Storage vMotion" which, like regular vMotion, allows me to move/migrate my VMs with zero downtime. Regular vMotion means I can move from ESX host to host (server to server). Storage vMotion allows me to move from Datastore to Datastore. Cool. The downside, Storage vMotion on ESX 3.5 is "command line" driven. The upside is that when we upgrade to vSphere 4, there's now a GUI for Storage vMotion. Let's get started.
Installation
Go here and download the Storage vMotion Remote CLI setup files. Start the setup.
Click Next.
Verify Install location. Click Next.
You're ready. Click Install. Magic Happens.
All done. Click Finish. This installs the Remote CLI componens and Active Perl. I had to reboot the machine on which I installed the Remote CLI tools. Your mileage may vary.
Let's Do Something
So, I want to sVmotion my Terminal Server called "TS01" – I did this a couple days ago moving it from about 50gigs of Datastore to 75gigs. But, because my 15k rpm SAN space is limited, I'm having to play "Towers of Hanoi" and first of all migrate critical app servers from 15k rpm to 7200 rpm… then back. So, you missed the first SVM, but you can get the details of the second.
So, you can see that my TS drives are in the Datastore called TS01_New. I keep my Pagefiles separated on their own Datastores using the fastest possible disks available. So, my Pagefile is on the Pagefile01 Datastore. That's important information. By default, sVmotion will migrate ALL disks to the "parent" Datastore unless you tell it not to. Let's go ahead and start the sVmotion. I use the "interactive" CLI version seen below (in its entirety)
First of all, you'll notice that I launched the Perl script manually from the Command Prompt in "interactive" mode. This is awesome. It walks me through everything I need to know.
- I chose the right vCenter url: https://cen-dc01.unity.com:4430
- I authenticated
- I entered the name of the affected VMWare ESX Datacenter: LC.tv CEN
- I then chose the right VM: [TS01_New] TS01/TS01.vmx
- Then I chose to move each vmdk (disk) independantly (remember that from above)
- I moved the "system" disk from the TS01_New to TS01_System Datastore
- I "moved" the Pagefile disk from the Pagefile01 to Pagefile01 (not really moving it) Datastore
- Then, the magic happens…
As the magic happens – notice that the "Active Tasks" updated on the TS01 VM – it's now in the state of "Relocate Virtual Machine storage" – and – also notice that the Datastores in use has updated.
About 40 minutes later (Your mileage may vary) the task completes.
And, notice that the Virtual Machine is now using the "new" Datastore – TS01_System – and also the Pagefile01 Datastore (which didn't change). All is well.
Anyway, I need to do this with another 16 Virtual Machines… I should probably get started…