As much as some of the Virtualization community would like - vCenter is a Windows application that means no Linux. VMware have released a CTP of an appliance that will run on Linux, but if you ask me - the project will never get off the ground - there just is not enough interest.
So a new server, new OS. Supported Operating Systems are (Compatibility Matrix):
- Windows XP SP2 / SP3
- Windows 2003 32/64 SP1 / SP2 / R2
- Windows 2008 32/64 Std/Ent/Datacenter
The de-facto OS that we deploy today for a server is Windows Server 2008 R2 64bit - and this was not on the list! Sure many people have installed vCenter on R2 and it works, but for a production environment - if you want VMware support - then you go with the supported components.No arguing!! So compromises had to be made on all counts and with the new OS installed, static IP set and all default components (monitoring, AV etc.) installed we were ready to go.
It is a big download so if you are using a 56k modem - I think you should drop this post and come back when they release vSphere 24 because it will take that long.
Just kidding, please stay with me……
While the download completes ….
I like to write down on paper (or in a txt file) what I have and where I want to go.
What I have
- Windows 2003 32bit R2 SP2
- vCenter 2.5 U4 on a DC Xeon with 2GB RAM
- License Server is on the the vCenter Server
- Database on a separate SQL 2005 server hosting the DB (and others as well)
- VMware Update Manager - on a VM in the virtual infrastructure
- Update Manager DB on the same SQL server
- VMware Guided consolidation
- x # of ESX hosts
- x # of Clusters
- x # VM’s
- x Number of Templates
Where I want to go (this stage only)
- Windows 2008 64bit SP2
- vCenter 4.0 Update 1 on a QC with 8GB ram (why I will get to in a minute)
- Database on on a separate Central SQL 2008 Server
- Update Manager installed on the same server
- Update Manager DB on the same Central SQL server.
- Same number of Hosts, Clusters, VM’s and templates as before.
- Converter
Since this was not an in-place upgrade - I could install the new hardware without any interference to the current vCenter, get all things configured, and when ready make the switch.
I will not walk you through the steps of installing the actual software - there are more than enough great posts around explaining how to do this. If you need to go over them and come back here in a short while.
Ok - Welcome back!!!
We now have a Second vCenter Server installed. I wanted to set up SSL authentication properly for my server (something that was not done in the current environment) and I wrote a lengthy post about my experiences and what I learned on the way so if you have not - I would suggest you give it a read.
Now you may ask - how do plan on migrating everything? Well fear not - I am about to tell you.
Moving an ESX host out of a vCenter server will remove the host and all VM’s from the Inventory but the machines and the host will still keep running - there will be no loss of connectivity for the end user. Sure you will lose the redundancy but we found this was an acceptable risk.
The migration plan was as follows:
- Work on a per-Datacenter basis
- Disable HA and DRS
- Disconnect the host from the Source vCenter
- Remove the host
- Add it into the Destination vCenter
- Do this for all Hosts in each cluster in the Datacenter
- Re-enable DRS and HA
Zero Downtime for all the users!!!!!!! It was a wonderful plan - it still is… but there were some flaws.
I do not know if you noticed but when you add an ESX host that has running VM’s into vCenter you have hardly any control over where your VM’s will be placed in the folder structure, you can choose one location (a Resource Pool) in where place all VM’s. For an existing environment this is not good, not good at all. There would have to be a lot of house keeping to be done in order to move everything back into its place.
But wait - I can can hear your thoughts - WHAT ABOUT PERMISSIONS??? I mean if there were permissions assigned to folders and VM, they would have to be set again.
And the custom attributes?? I have custom attributes that are set for each VM - they will also be lost.
Of course all of these settings should be documented before you start, so that to keep the record of what was set before an restore it if possible, but to do this by hand would take ….
………. a long time.
I wanted to try and save myself some time (in the end I think the amount I time I spent on the solution was probably the same as if I would have done it manually - but the learning experience was more than worth it) I wanted to automate the solution as much as possible, and what better way to do it than with PowerCLI
The how? - that will have to wait for the next post.