vCenter Server 4 as VM considerations

T

Thuleman

Supreme [H]ardness
Joined
Apr 13, 2004
Messages
5,833
I know it's not "best practices", but it is what it is, and I will be running vCenter Server 4 as a VM just as I am running the 3.5 as a VM. I will also be running SQL server on that same VM. I have three physical hosts and less than 30 VMs to administer.

The ESX and vCenter Server Installation Guide (vmware.com, pdf) lists as minimum requirements for vCenter 2 CPUs. I would assume that in the hardware world a dual core chip would do. However, at least in ESX 3.5 it was always said that giving a VM a single CPU is the way to go.

My question is, how does that relate to vCenter Server 4? Does anyone have experience deploying it as a VM? Any feedback?
 
Seems fine. I'm not sure why they are suggesting two CPUs in the new version. So far I haven't seen the need but it's possible for some larger installations with some of the new performance tracking it may be needed.
 
Yeah, 2 cpu's is suggested for up to 50 hosts, over that, they recommend 4. I think with only 3 hosts you'll be fine with 2 vCPUs, you're not even coming close to the 50 hosts, I haven't seen anything on running vCenter Server in a VM yet though.
 
I strongly dislike vCenter as a vm.

Any time your management system is tied to the thing it's managing, you're asking for trouble. have to resignature a bunch of volumes? Say goodbye to vcenter, it's gotta come down - makes life fun.

Have a Lun down and need to reboot a host? Vcenter may be a VM on it that's down on that lun - can't vmotion vms then to do it live, since you can't vmotion without it!

License server on VC down and now everything is unlicensed and expired, but you can't power on the VC vm because, yep, it's unlicensed and can't power down? Fun! Rebuild time!

Circular dependencies are not that good :(

Anyway, I understand that you have to keep it that way - that being said...

1vcpu will still outperform 2. I'd still stick with 1vcpu on a VMed Vcenter over 2 - I don't know of any changes made that would benefit from the changed scheduling.
 
Yeah..by fine I meant, "in the lab", not production. Your points are exactly what I tell customers when they ask this inevitable question.
 
I am not too worried about the drawbacks really. I only have one SAN unit, so if there's something wrong with shared storage I am hosed either which way. The vCenter functionality isn't essential to normal operation, it's more of a convenience. It's a small setup I run here, and none of it is mission critical in a real world business sense. Even several hours of downtime, while not optimal, are acceptable.

Will stick to one CPU then, thanks for the advice.
 
Cool then - it works great for testing labs/backup vcenter (linked mode ftw!)/dev labs, and if you don't mind the downtime, it's fine too :)
 
I know it's an older thread, but I just figured something out that's imho worth posting:

lopoetve said:
License server on VC down and now everything is unlicensed and expired, but you can't power on the VC vm because, yep, it's unlicensed and can't power down? Fun! Rebuild time!
Click to expand...

This is actually a really big problem, and strangely there's no good way to avoid that.
The licensing for hosts can either be host based, or centralized, meaning one can either enter the license key directly on the host through the vSphere client, or one can have vCenter manage the licenses.

However, what one can not do is manage the hosts using vCenter and use a host based licensing scheme. Whenever vCenter is used, the licensing for all hosts managed by vCenter has to be centralized through that vCenter.

I just went round and round with the licensing team because I would enter a valid license key through vClient, it would decode and install the license as root, and shortly thereafter vpxuser would revoke the license and return the host to eval as vCenter sees it. The only want to fix that was to either disconnect the host from vCenter, then enter the license key, and not reconnect that host to vCenter, or have vCenter manage the license.

Now, conceivably, in a three node cluster, with FT on the vCenter VM, this becomes less of an issue, but it's problematic nonetheless imho. What I mean by that is that's it's a problem either which way, it doesn't really matter whether vCenter is a VM or not. Even if it isn't a VM, if it goes down, so does your licensing.
 
well, there IS a 14 day grace period when your licenses go unavailable... fwiw.

And since the license server can run without VC (on 2.5/3.5), it's not as bad. In 4, it should still have the grace period, but yes - if VC is down, everything down. At least it's possible to rebuild a physical VC vs a virtual though - you'd have to reinstall an ESX host to rebuild a VC vm.
 
Thuleman said:
I know it's not "best practices", but it is what it is, and I will be running vCenter Server 4 as a VM just as I am running the 3.5 as a VM. I will also be running SQL server on that same VM. I have three physical hosts and less than 30 VMs to administer.

The ESX and vCenter Server Installation Guide (vmware.com, pdf) lists as minimum requirements for vCenter 2 CPUs. I would assume that in the hardware world a dual core chip would do. However, at least in ESX 3.5 it was always said that giving a VM a single CPU is the way to go.

My question is, how does that relate to vCenter Server 4? Does anyone have experience deploying it as a VM? Any feedback?
Click to expand...

Actually, it is best practices. It gives redundancy of the vcenter server if being used in a cluster with vmotion/DRS enabled.

I have yet to deploy it as a VM, our company is of course cheap when it comes to fully funding the IT department, so we have esxi with veam back up(i.e. cheap as hell since licensing is only the veam software).

i can tell you, as a VCP, vcenter server is recommended by vmware to be a VM, for the reasons I said above.
 
himmy said:
Actually, it is best practices. It gives redundancy of the vcenter server if being used in a cluster with vmotion/DRS enabled.

I have yet to deploy it as a VM, our company is of course cheap when it comes to fully funding the IT department, so we have esxi with veam back up(i.e. cheap as hell since licensing is only the veam software).

i can tell you, as a VCP, vcenter server is recommended by vmware to be a VM, for the reasons I said above.
Click to expand...

It is supported, that does not mean it is a best practice. Tthere are considerations that have to be made both ways. VC as a VM ties your management to your environment, which can be a problem when the entire thing is down, especially if for some reason the licence redundancy period is passed (it happens). Even more so if DNS is only in a VM as well.

How in the world are you ever going to start things up when your ESX hosts won't start a VM because the license server is down but the license server is a VM? How do you expect to resignature a set of luns when each host is tied to datastores and can't be managed together because VC is one of the VMs down on a resignatured lun? How do you get your storage back up when your DNS vm is down and you used DNS for NFS to use a clustered filer head, which means your storage is down and you can't even access that VM? These are all cases I've seen, most of them multiple times.

Circular dependencies are bad. They make simple support issues far more complex, and greatly increase time to resolution.

I stand by my recommendation - for the most reliable environment, you want a DNS/DC server not tied to ESX, and your VC/license server also not tied to ESX. Cluster it if you really want to even, just don't tie it to your virtual environment. Throw everything else in there, sure - but if your management is in there, you'll find yourself on the outside looking in some day when you wish you weren't.
 
Last edited:
In fact, our Very own Sabregen had this issue:
http://www.hardforum.com/showthread.php?t=1412353 (post 15)

:) Fun times were had by all, and it's not hard to work around, but it is something you have to work around.

You have to balance the reliability / not tying it to hardware vs having your management in the environment. At the very least, make sure you have a box of SOME kind (even a workstation VM) to rebuild it in if you have to, in a hurry - it may save you hours ;)
 
lopoetve said:
It is supported, that does not mean it is a best practice. Tthere are considerations that have to be made both ways. VC as a VM ties your management to your environment, which can be a problem when the entire thing is down, especially if for some reason the licence redundancy period is passed (it happens). Even more so if DNS is only in a VM as well.

How in the world are you ever going to start things up when your ESX hosts won't start a VM because the license server is down but the license server is a VM? How do you expect to resignature a set of luns when each host is tied to datastores and can't be managed together because VC is one of the VMs down on a resignatured lun? How do you get your storage back up when your DNS vm is down and you used DNS for NFS to use a clustered filer head, which means your storage is down and you can't even access that VM? These are all cases I've seen, most of them multiple times.

Circular dependencies are bad. They make simple support issues far more complex, and greatly increase time to resolution.

I stand by my recommendation - for the most reliable environment, you want a DNS/DC server not tied to ESX, and your VC/license server also not tied to ESX. Cluster it if you really want to even, just don't tie it to your virtual environment. Throw everything else in there, sure - but if your management is in there, you'll find yourself on the outside looking in some day when you wish you weren't.
Click to expand...

VMWare recommneds it. that basically means best practices.

As for your questions, you have a 14 day grace period, your ESX boxes will be fine without VC server for 2 full weeks.

As for bad LUNs, DNS, and every other example you gave: storage vmotion, vmotion, DRS, affinity/anti-affinity rules, HA, etc, etc, etc.

In a properly built cluster, your virtual infrastructure is as close to being bullet proof as humanly possible.

Also, lets say you only have one esx/esxi box, so no redundancy. All you need is a copy of the vcenter server VM, which you can automate every single night, and fire it up in VM Player in worst case scenarios.

Vm's are nothing but files, no hardware reliance. if you have a back up of all your VM's, they are extremely easy to get going in a very small amount of time. if you do not have a back up of all your VMs, the failure rests solely on the individual that because lazy and was not properly backing up their infrastructure.

http://www.vmware.com/pdf/vi3_vc_in_vm.pdf
 
Last edited:
No where in there does it say it's recommended - we support it, just like a physical box, and there are advantages and disadvantages to it, the same as anything.

Plenty of times I've seen the grace period excepted or passed. There are ways to forcibly expire it too if you don't know what you're doing.

Storage vmotion from a bad lun? Gotta have space free, most places don't, and that's assuming you haven't lost access to the VMX file already, and have low enough load to do it. Not to mention that you're assuming that you're still up. Vmotion won't work if you can't access the vmx file, which you generally can't in most of those issues. HA won't help either since it's also a licensed feature AND relies on DNS AND relies on VC being up and runnning (VC ha relies on the cache, so if it's down too long, it may not function as you expect - HA can and will ignore affinity rules/anti rules in these cases, especially with VC down).

Nothing is bulletproof. Building for the best reliability is the way to go, unless you enjoy paycheck instability ;) I fix this stuff every single day, this is something I see far too often.

edit: Removed error..
Getting things up nad running is even FASTER when you don't have to rebuild esx hosts to get things up and running, or import appliances/vms to other systems. Downtime is money lost, build for reliability.

Trust me here, I'm infinitely more familiar with the product than you expect. Take a look at Sabregen's case. You'll understand :)
 
Last edited:
edit: I'm double checking that vsphere esx vms won't run in WS/player. In 3.5/WS6 they wouldn't without conversion or vapping.
 
ok, correction - you CAN go ESX -> ws. You can't go the other way still without converting. Good to see they finally fixed that. Even then, this requires you copying off the VM regularly - not the most optimal solution. Watch out for maxfilesize issues on FAT32 though - not hard to blow past it, if you're using FAT32 (lots of external disks are formatted as such).

It's a supported option - you just have to consider all the advantages and disadvantages to it.
 
lopoetve said:
No where in there does it say it's recommended - we support it, just like a physical box, and there are advantages and disadvantages to it, the same as anything.

Plenty of times I've seen the grace period excepted or passed. There are ways to forcibly expire it too if you don't know what you're doing.

Storage vmotion from a bad lun? Gotta have space free, most places don't, and that's assuming you haven't lost access to the VMX file already, and have low enough load to do it. Not to mention that you're assuming that you're still up. Vmotion won't work if you can't access the vmx file, which you generally can't in most of those issues. HA won't help either since it's also a licensed feature AND relies on DNS AND relies on VC being up and runnning (VC ha relies on the cache, so if it's down too long, it may not function as you expect - HA can and will ignore affinity rules/anti rules in these cases, especially with VC down).

Nothing is bulletproof. Building for the best reliability is the way to go, unless you enjoy paycheck instability ;) I fix this stuff every single day, this is something I see far too often.

Yes, I know they're nothing but files, but versions differ, and you cannot fire up an ESX vm in player/workstation. They're NOT the same kind of file, unless you're exporting them as a v.appliance. Getting things up nad running is even FASTER when you don't have to rebuild esx hosts to get things up and running, or import appliances (hint- vcb backups and the like won't fire up in workstation or the like either) that most people don't have. Downtime is money lost, build for reliability.

Trust me here, I'm infinitely more familiar with the product than you expect. Take a look at Sabregen's case. You'll understand :)
Click to expand...

You ignore tools that are available to you. yes, you can't just fire up an ESX vm in player or workstation. You run the converter and you are good to go. i was guessing since you know so much about vmware, you would have already known this and automatically realized what i was saying.

You are also taking examples and applying them wrong. Like storage vmotion from a bad LUN. one, if you do not have a back up of each VM to bring up on another host, then i do not know what to tell you. If you do, and that is not the first place your brain tells you to go to, then i also do not know what to tell you. VCB is built in, easy to use, and extremely flexible with the software it works with to fully back up any VM, from file level to block level.

if they do not have any more space to bring up the VM, then that business is shooting themselves in the foot and they have removed redundancy out of their virtual infrastructure and introduced a single point of failure. Bad, bad, bad.

All licensing needed to be able to vmotion, HA, DRS, etc is good within the 14 day grace period, even with host reboots.

It is basically like me saying to have vcenter server on a stand alone box is dumb because if that box has a hardware failure, you lost everything. Well, that box should be backed up anyways, if not with a full image, so it can be brought back up easily within the 14 day grace period.

i think the big key you are missing here is what i said all along, when in a properly configured virtual infrastructure, vcenter as a VM is perfectly fine. This includes redundancy with networking, SAN, etc.
 
All I'm telling you is what I see, every single day, and what I recommend. There are advantages and disadvantages, and I've seen major companies totally shut down because they had one thing relying on another that relied on the first again. Having NO backup DNS and having NO backup AD controller and no backup VC is a good way to take a 1 hour call to to VMware support to a 4+ hour call and tons of lost money. And I see it every single day.

There are plenty of ways for the 14 day grace to break or be missed. If LM isn't working properly, there is ~no~ warning given by the hosts up till the minute they go unlicensed. There are also ways to cause the grace period to break.

Is there a workaround? Sure, but it's a heck of a lot faster to not have to workaround in the first place, and just fix the initial issue. Even properly configured, stuff still breaks - no software is perfect, and relying on software to BE perfect is a horrible idea.

If Vcenter is a physical box and goes down big deal. Nothing happens. If it's a VM and your environment breaks, then guess what? You have no easy way of managing the entire environment at the same time to fix it. No vmotion, no storage vmotion, no converter, etc. You lose a LOT of options you don't even realize exist. Restoring backups is much slower than fixing the issue in the first place, even with VCB.

Reality check: Businesses shot themselves in the foot every day. Sad but true. Budgets are tight, purchasing is down, and people are making do with what they have. You may have tons of options, but that doesn't mean everyone does.
 
oh great...I'm leading by example!? :p That was a NOT fun situation. It has forced me to ensure that NO local VMFS3 partitions are contained on host boot LUNs, at all. If they exist, I kill them.

I would also (based on my own experience) recommend NOT running the vCenter as a VM, inside the environment as THE ONLY management of the environment. I would prefer a VM in the environment, and one as a physical box OUTSIDE the environment.
 
<3! ;) :D

My advocacy is simple: You want a backup of your management outside the environment at the very minimum. Since VC can't have a backup (in 3.5), run it outside so that it's not tied to your environment. Linked mode in 4 would probably do it too, but I've not tried pulling a linked mode VC down to test. You also want a secondary DC out there (in case somehow AD lookup gets messed up - don't ask me how, but I've had to fix it), and a secondary DNS server. Just to keep things running if all goes AWOL.

That way, no matter how fubar your ESX hosts get, you've got your main infrastructure running and can actually go in and fix it. It's always fun getting hte call and having someone tell you that they're on their cell phone because the PBX is out, DNS is down so they can't connect out for you to dial in, and they can't do anything since VC is down and nothing will start.
 
i just upgraded my esx 3.5 to 4 and my VC, all my DCs and DNS were vms, doable but not fun, I have a backup VC as WS vm but I'm now thinking of having a real AD, DNS, VC outside of my vmware environment.
 
yeah if i had the budget i would have my second dc and dns outside of esx along with vc on a physical box.
 
Running it as a VM does pose some interesting dilemmas at times. Such as resolving issues if you lose connectivity to that VM or port group, etc. However, we currently run it as a VM with mostly no issues. And it is recommended to be a VM by VMware.

As for the 2 CPU suggestion, we have a fairly small environment (3 hosts, ~40VMs) with VCS4 running as a VM with 2 vCPUs and it throws the CPU utilization alarm rather frequently. It is usually due to VCS doing maintenance/processing on its database.
 
SatanSkin said:
Running it as a VM does pose some interesting dilemmas at times. Such as resolving issues if you lose connectivity to that VM or port group, etc. However, we currently run it as a VM with mostly no issues. And it is recommended to be a VM by VMware.

As for the 2 CPU suggestion, we have a fairly small environment (3 hosts, ~40VMs) with VCS4 running as a VM with 2 vCPUs and it throws the CPU utilization alarm rather frequently. It is usually due to VCS doing maintenance/processing on its database.
Click to expand...

Again, it's not recommended, it's supported. It has advantages and disadvantages that must be weighed. :)
 
You must log in or register to reply here.
Back
Top