Our current VC is a physical server and also contains the VC database. I would like to virtualize the VC and was wondering if virtualizing the SQL database was something I should do also? Or is there a reason I shouldn't virtualize the DB? I would still utilize the standard backup process for backing up the VC DB but i thought if I virualize the VC then why not the DB also.
Does anyone have the steps needed to do this? The VC name will change as well as the ip address.
Thanks
running VC as a VM is supported, but I think the thing to look at is what is best for your enviornment. I have worked in places where they had VC running as a VM while having the SQL database on that same VM. I also, have worked at a place that had VC running in a VM, but the SQL was backened on a physical SQL cluster.
My current preference, which is how we are set up now. Having VC running on a seperate physical box and having the SQL 2005 cluster running on a MSCS clustered hardware solution.
If you are building a new VC instance with a different HOST name and IP, the easiest wasy to me to migrate all the information, is to have both instances up at the same time.
running VC as a VM is supported, but I think the thing to look at is what is best for your enviornment. I have worked in places where they had VC running as a VM while having the SQL database on that same VM. I also, have worked at a place that had VC running in a VM, but the SQL was backened on a physical SQL cluster.
My current preference, which is how we are set up now. Having VC running on a seperate physical box and having the SQL 2005 cluster running on a MSCS clustered hardware solution.
If you are building a new VC instance with a different HOST name and IP, the easiest wasy to me to migrate all the information, is to have both instances up at the same time.
Thanks for the information. That's what I was looking for.
you're welcome, glad I could help.
Any love for points?
Did I give you the points correctly? I'm not that familiar on how to give them but I did click correct answer for your response.
Did I give you the points correctly? I'm not that familiar on how to give them but I did click correct answer for your response.
It's all good! Thank you!
You've done it correctly. You can assign one post as correct and up to two as helpful.
Keep in mind if you VM your VC and something goes wrong with VC or your VMware cluster goes nuts you just lost your primary management tool...
Thanks for the input. Why would my vmware cluster go nuts? Has this been a problem? In either case I will have a backup of the VC database I could restore to a new VC server and should be fine correct? Also having backups of full snapshots of the virtual VM should help with any recovery.
Thanks again!
We run our VC and Oracle DB for it in a VM. The worst that has happened to us when Virtual center has gone down is that we have had to play find the ESX host that has the vritualcenter VM on it.
The latest version of VC introduced DRS Storms that caused massive issues when you put a server into maintenance mode that caused huge numbers of migrations that were not necesary, if you search for DRS issues you will find a lot of posts on this issue (soon to be resolved, we hope!!!)