Tag Archives: migration

Test lab

These days I’m waiting on my functional users to finish testing a large upgrade of our Oracle Apps environment.  So far *fingers crossed*, they have yet to find many issues that require my time, so I’m having plenty of time to work on side projects.

This past week I build up a VMWare test lab with some de-commissioned hardware we had lying around.  The test lab consists of

  • Dell 2950 with 4 cores and 16GB of RAM, 300GB RAID 5 local storage
  • Dell 2850 with 4 cores and 9GB of RAM, 300GB RAID 5 local storage
  • Iomega Storcenter ix4-200d  2.7TB RAID5 NAS storage (NFS / iSCSI)
  • ESX 4.0 (vSphere) plus all patches thru 3/17/10
  • vCenter 4.0

I admit, for de-commissioned hardware, it’s still a pretty powerful little cluster.

We’re about 3/4 of the way thru our upgrade from ESX 3.5 to vSphere on both our primary cluster and our DR (Disaster Recovery) cluster.  At this point we’ve got all the ESX hosts upgraded to vSphere.  The next steps are to get those hosts with all the latest ESX patches and then update the VMWare tools (which will cause a momentary downtime for the network of the VM) and the VM hardware layer (which requires the VM be shut down) of each VM running in the cluster.  Due to business requirements for when we can bounce certain VMs, this is a process that will take a week or two to get done.

In addition to our primary and DR clusters, we also have 6 standalone ESX 3.5 boxes with no shared storage.  Some of these run somewhat critical virtual machines and so minimizing downtime is important.  That’s where the test lab is coming in.

Besides providing a non-production environment for me to learn and test out various things with VMWare, I’m utilizing the Iomega StorCenter as shared storage.  The plan is as follows.

  1. Add the NFS Share on the StorCenter to the ESX 3.5 Server.
  2. Utilize Storage Vmotion to move the datastore for the VMs on the ESX 3.5 Server to shared storage
  3. Utilize Vmotion to move the running VM from the ESX 3.5 Server to the ESX 4.0 Servers.

So far, no downtime.

Once we’ve moved all the VMs off the standalone ESX 3.5 server, we’ll upgrade the various BIOSs / Firmwares on the ESX host and then install a fresh and fully patched version of vSphere.  Then we’ll re-attach it to the shared storage and move our VMs back.  Finally, we’ll schedule downtime with the respective business owners of those VMs for some downtime to upgrade the VMWare tools and the VM hardware version.

It’s a good little project that lets us leverage many of the cool features in VMWare and should provide quite the fun learning experience.

And for those of you scratching your head and wondering why we are choosing to run somewhat critical VMs on only localized storage – we’re finishing up an expansion of our server room and upgrading to a larger SAN so we can eventually store those VMs in the SAN.  The StorCenter might be used once we’ve upgraded all these standalone ESX boxes as a temporary home, but we’ll have to see.