I'm currently running VC 2.0.2 Update 1 managing three ESX 3.0.2 Update 1 hosts. VC is running as a VM under VMware Server completely outside of the ESX/VI3 environment. Why am I doing it this way? I don't really know but that's how I originally set it up. ![]()
I'm now looking at wanting to implement VC 2.5 and eventually ESX 3.5. I've built a Windows 2003 VM within my ESX environment, installed VC 2.5, and installed my license. At this point can I simply remove the hosts from VC 2.0 and add them to VC 2.5? Can this be done while the VMs are running? Is this something that is best done outside of normal business hours?
VC 2.0 is currently using MSDE which is running in the same VM as VC. For VC 2.5 I've installed SQL Express in the same VM as VC 2.5. Do I need to worry about copying the old database over and upgrading it? Or do I not need to worry about it? Do I basically just lose historical performance information by migrating this way?
Am I correct in assuming that once all the hosts are being managed by VC 2.5 I can then upgrade to (or blow away and do a fresh install of) ESX 3.5?
Any and all help is appreciated! Thanks!
Joe
Hi,
Because you cannot have ESX hosts registered (or added) to more than one VC Server at a time, once you have installed VC 2.5 you will need to remove the hosts from VC 2.0. In order to remove the hosts from a VC server, you will have to put them in the 'Maintenance Mode' and the host won't go in a maintenance mode unless you have shut down the VMs (or moved the VMs).
AFA running VC in a VM is concerned, support should not be a problem (that's what we were told in the VMware course! me too
actually I faced this problem myself) And you cannot VMotion a VM between hosts having different types of CPU. So its kind of strong dependency loop!!
HTH
Once the VC 2.5 server is setup, you are correct in your assumption about moving the hosts. It will not effect VM performance, aside from the features that require VC Server to function, and only while you are moving things over. If you do not move the database over, you will lose your historical data...it's up to you how important it is to retain this information. Once everything is moved over, you can begin the upgrade to ESX 3.5.
Sounds like you know what to do, just wanted a bit of confirmation :smileygrin:
Hello,
Watch out with MSDE and SQL 2005 Express. I believe you will find that both are not supported in production enviornments.
If you move your hosts between VC servers you will need to reregister your templates, reimplement security controlls and hierarchies if you have them. If your environment is small though it won't be a big deal.
Also, you will want to be current with patches on your 3.0x ESX hosts before they are managed with VC 2.5 as that is a requirement.
Otherwise it should be a pretty straight forward process.
Once the VC 2.5 server is setup, you are correct in your assumption about moving the hosts. It will not effect VM performance, aside from the features that require VC Server to function, and only while you are moving things over. If you do not move the database over, you will lose your historical data...it's up to you how important it is to retain this information. Once everything is moved over, you can begin the upgrade to ESX 3.5.
Just to be safe, then, would you say it's probably best to move the hosts over after normal production hours?
Sounds like you know what to do, just wanted a bit of confirmation :smileygrin:
It just sounded too easy so I thought I'd post here to make sure there wasn't something I was missing.
Do you know if VC is officially supported as a VM under ESX now? I had heard that it wasn't in 2.0 but supposedly was in 2.5.
Joe
With the way VMware words it, SQL Express 2005 is supported in production for small environments (See screenshot from ).
I did a little reading here in the forums before I posted and thought I saw someone post that SQL Express was supported for up to 5 hosts and 50 virtual machines. In my environment I'm at 3 hosts and about 20 machines, and I don't see that expanding much beyond 30 virtual machines. From the wording in the install guide there it sounds like my situation should (hopefully) be supported.
I wouldn't run it because of the issues with historical data collection (KB1003570), but that may not be a concern of yours.
Yeah that's not really that big of a deal to me. It's just not worth going out and buying full blown SQL 2005 just for this. Now if VMware would go out and support MySQL it'd be easy for me to move to an enterprise database. Not only is MySQL free, but we already use it as our main production database. But for now I'll just deal with SQL Express and worry about the historical thing later.
One quick question, according to the KB article you mention, "Historic data is managed by the VirtualCenter Server service." Does that mean in theory there should be a way to get historical data if you're using SQL Express meaning no access to the SQL Server Agent?
Joe
Hi,
Because you cannot have ESX hosts registered (or added) to more than one VC Server at a time, once you have installed VC 2.5 you will need to remove the hosts from VC 2.0. In order to remove the hosts from a VC server, you will have to put them in the 'Maintenance Mode' and the host won't go in a maintenance mode unless you have shut down the VMs (or moved the VMs).
AFA running VC in a VM is concerned, support should not be a problem (that's what we were told in the VMware course! me too
actually I faced this problem myself) And you cannot VMotion a VM between hosts having different types of CPU. So its kind of strong dependency loop!!
HTH
Because you cannot have ESX hosts registered (or added) to more than one VC Server at a time, once you have installed VC 2.5 you will need to remove the hosts from VC 2.0. In order to remove the hosts from a VC server, you will have to put them in the 'Maintenance Mode' and the host won't go in a maintenance mode unless you have shut down the VMs (or moved the VMs).
That's what I was afraid of. I figured I couldn't just "remove" a host from VC 2.0 while VMs were actively moving. And I don't see how I can VMotion VMs from one host to another if each host is being managed by a different VC. I figured the best bet would be to shutdown all the VMs (meaning doing this after hours), move the hosts, the start the VMs.
AFA running VC in a VM is concerned, support should not be a problem (that's what we were told in the VMware course!!). However, TECHNICALLY
if you are running a VC and the license server on the same VM and if that VM goes down, after the grace period has expired you won't be able to bring new VMs up which translates into no V+license server (in this case).
I'm essentially in that situation now as I run VC in a VM. The only difference is that currently it's under VMware Server, so even if I shut all ESX hosts down the first one that comes back up would be able to get a license as long as that separate box running VMware Server is up. Under the new scenario that first host wouldn't get a license initially so I'd have to configure things to make sure that the VC VM is always powered up automatically.
Also if a VC is a VM, then if you need to bring the host (on which the VC VM is running) down for maintenace you have to either a) move the VM to another host OR b) you have to shutdown the VM. If you shut down the VC VM you cannot remove the host. (confused?! me too
actually I faced this problem myself)
So I'd just have to make sure to VMotion the VC VM over to a different host to do my maintenance. That shouldn't be too big of a problem. After all today when I want to run maintenance on a host I have to migrate all the VMs over to another host and I only do one host at a time.
And you cannot VMotion a VM between hosts having different types of CPU. So its kind of strong dependency loop!!
Not a problem here. The servers due have different Xeon processors in that one is a dual-core while the other two are quad-core, but they're the same "class" or whatever Intel calls it so that VMotion works across them all. Plus soon I plan on upgrading the CPUs across all three so that they will actually all be identical plus be faster than what I have today.
Thanks for the tips!
Joe
