Slashdot Mirror
Ask Slashdot: What Type of Asset Would You Not Virtualize?
An anonymous reader writes "With IT and Data Center consolidation seemingly happening everywhere our small shop is about to receive a corporate mandate to follow suit and preferably accomplish this via virtualization. I've had success with virtualizing low load web servers and other assets but the larger project does intimidate me a little. So I'm wondering: Are there server types, applications and/or assets that I should be hesitant virtualizing today? Are there drawbacks that get glossed over in the rush to consolidate all assets?"
Shared disk does not make I/O happy.
Working...
Virtualize management.
Have gnu, will travel.
Assets not to virtualize:
1) Women
2) Beer
3) Profit
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
ibm even says give it its own physical machine if you're going to virtualize it.
Food, cigarettes, and ammunition
The company cafeteria isn't all that great, but jeez nothing is less satisfying than a virtual burger and virtual fries.
Sig Battery depleted. Reverting to safe mode.
Gold, houses, aircraft carriers, 17th century Dutch paintings.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
How about backups?
Consolidating and virtualizing your backup servers sounds like a recipe for trouble to me.
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
My organization has virtualized almost every workload you can think of including Exchange, our ERP system, our big HR system, and other huge enterprise applications on top of VMware vSphere.
The only things we do not virtualize at this point are our really big Oracle databases, but those are in effectively virtualized on the Oracle RAC platform anyway.
I tend to hear people in smaller shops who don't really have that many users being more fearful of virtualization which is the opposite of what you'd expect.
Yo Mama.
I would not virtualize the servers that are running the virtual machines.
Why you wanna virtualize an asshat?
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
Do you sense a growing suspicion that Facebook has been counting virtual revenues...?
Well yes Databases would make a poor virtualization target. Also your heavy memory usage java app like the company app server using a terabyte of ram to display the department wiki.
Got Code?
Seems like a front-end serving statically cached content is a great match for Virtualization. DB servers and search servers (Solr, etc) aren't a good match imho, unless you have a very well implemented sharding/horizontal scaling solution. If you pre-generate your content, we've typically used hard boxes for those as well, but you may benefit from virtualizing those if you want to easily scale horizontally (assuming you have the hypervisor overhead).
I wouldn't virtualize compute clusters: medical, bio, etc....I use render farms for images and VM's don't really help with performance.
Management is another topic, but that can be accomplished without VM's.
-nick
Having DNS virtualized can make it hard to start vCenter. Also, you probably don't ant to virtualize your vCenter SQL backend.
Don't virtualize anything requiring tight scheduling or a reliable clock, such as a software PBX system performing transcoding or conferencing.
http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
Pretty much anything can be successfully virtualized if you throw enough hardware at the host. Just keep in mind that these machines are all actually running on the same processors, and there's probably going to be a way to escalate rights from VM to host or VM to VM. In your environment this may not be an issue, but it's worth keeping in mind.
That's for sure... for now!
Yes, having the branch servers (domain/user profile) centralized saves on server hardware and maint, but that gets eaten up the first or second time a subcontractor has to wait 6 hours for a profile to load over a satellite link. I know. I'm that contractor.
Any heavy number-crunching will suffer from being virtualized.
The only workloads that you can't really virtualize tend to be things like OS/400, but that is where things like LPARs can come in OR workloads that do a lot of privileges calls to the CPU or a specific instruction set. Also there are a slew of non-technical reasons I've seen like in Healthcare or Pharma where a specific machine is written into a specification for drug manufacturing or such.
Even still there really aren't any workloads you can't virtualize and realize some sort of benefit from. Even those with high requirements for CPUs or Memory hogs can be virtualized. It's not always the best financial decision from the hardware cost and licenses, but most organizations benefit then from the ability to move the VM from one physical host to another to avoid downtime and easier backups. Having worked on a lot of the largest VMware deployments out there, I've yet to find an application we can't virtualize for some gain in performance (newer hardware) or get better resiliency (less downtime, easier backups, HA features outside of the OS).
I can only please one person a day. Today is not your day, and tomorrow does not look good either.
- Telephony and rea-time voice/video servers (Asterisk for example). You don't want to explain to your big boss why his phone lines are having hiccups :) Preferable to have an old Pentium running that one somewhere.
- Real-time servers, like game servers (Minecraft), as they constantly take up resources.
- NTPD servers (Network Time Protocol). Worst case, run it at layer 0 (host machine). But not VM
If you look at the pattern, these are all real-time services that have very little leeway for latency. Yes, it's possible to virtualize them, but it's more work than it's worth, really.
For me, IMHO, everything else is fair play. Had good luck with Windows Active Directory servers (yes even PDC), SVN, web services, file servers, databases, memcache, and many others.
Makes little sense to not run on metal when using an HPC. I can understand the benefit of being able to better utilize the hardware you have, as well as the potential lessening of your datacenter footprint in space, cooling, electric, etc. but when you are dependent on having quick(and ever quicker) turn around times because of business needs, it hasn't been my experience that the cloud makes sense, at least in production environments. Granted, for Dev & QA HPCs, go for it, but not for production.
Most things you can virtualize, even if you only have the 1 VM on the machine it does allow for easier migration between physical hardware (especially if Windows based).
Heavy I/O tasks you might not want to, if you do, local/DAS dedicated storage is preferred, if you virtualize these, it quite possible you want to have 1 VM to the 1 Physical machine, it doesn't save you space but as stated above can make things easier for migration between hardware.
Management and Monitoring you can virtualize but do so with local storage, not network based (iSCSI, AoE, NFS). If you must use shared storage make sure you have 2 on seperate arrays.
The backup server is OK to virtualize, but we keep the backups on local storage and tape, not on the shared array - the reason is the same as with the managment and monitoring not being on the shared storage array. If it goes down so you lose all machines operating off that array.
except BIG backend databases and keep your DBs separate from any disk groups used for virtualization
The best test environment is production. - Me
chrome://browser/content/browser.xul
I have seen the time on virtual machines hopping around -- even those that are running ntpd.
The real "Libtards" are the Libertarians!
My suggestion, based on past experience, is to check with your third party vendors and make sure they will continue to support their software in a virtualized environment. I've run into a few who basically said that if their product wasn't running on real hardware than they wouldn't support it any longer. It doesn't happen often, but check just to make sure.
Let's take this one step at a time. What does virtualisation do? Well, it lets you split up one big, beefy system into a large number of smaller, not-quite-so-beefy systems. In the process, I/O becomes essentially random (because while host A may be reading sequentially from its disk, and host B may be reading sequentially from its disk, and host C may be reading sequentially from its disk, that means that the disk - if those virtual disks are coming from the same spindle - is jumping from A to B to C to A to B to C to A to B to C, and performance is going to go through the floor. Remember this story? Yeah, that's exactly what I'm talking about.)
So anything that has high CPU requirements, or high I/O throughput requirements, probably shouldn't be virtualised. Anything with high RAM requirements might be a candidate for virtualisation alongside low-RAM applications, if the CPU and I/O needs are low, as long as the physical machines running the virtual hosts have an imperial buttload (that's the technical term - the metric buttload is smaller) of RAM. Everybody's situation is different; you'll know this better than anybody on slashdot.
On the contrary, these instructions are run directly by the host processor at full speed.
VMware emulates the rest of the computer, but it's just time-slicing the CPU to the emulator, so pure CPU runs more or less at full speed.
Please note in your virtual machines that the CPU is not virtualized, it is the same make and model as your actual hardware.
It's I/O that suffers with virtualization, because the I/O devices have to be emulated.
Have worked with some of the largest virtual environments in the world for several years.
My personal primary rule is: Don't virtualize anything important that has to have high availability. Virtual environments are great until they blow up spectacularly.
ACID compliant databases require a fast disk subsystem. Don't shirk on those.
That said, we do have an asynchronously replicated hot-standby that's a VM, but that's just so we can snapshot the thing and get a simple-sick backup / recovery / DR solution.
Worst case scenario, the fail-over site in Pittsburgh will spin up the VM and at least be running. Maybe not top-notch, but business will continue -- and that's the important part.
Meanwhile, at our primary DC, we get wicked-slick performance on real hardware for our DB's.
I wish I could virtualize our continuous integration build system and get rid of all the machines, but it needs to run unit and performance tests that rely on specific hardware like different types of GPUs, CPUs and peripheral devices.
our physical build boxes destroy the VMs in the build farm. not even close.
Also, thinking about prior art is willful infringement. This one goes to 11. Don't even look at it.
Food and water.
File under 'M' for 'Manic ranting'
Most database servers are already doing the same things that virtualization accomplishes. SQL Server 2012 as an example can support multiple database instances, each with multiple databases and will use every last resource available, and be more efficient than hosting multiple copies of in their own OS instance in VMWare.
Along with virtualization management, do not virtualize whatever system provides authentication to allow you to manage the VM's (domain controllers in the case of hyper-v). Other than for hardware requirements (PBX, phone interfaces,anything requiring proprietary hardware) everything else is fair game. The list of hardware that can not be accessed by a VM is getting shorter, as virtualization giants have started to support giving VM's some GPU time on the host, as well as access to USB devices.
There's very little I would not virtualize however, you must size your supporting hardware correctly. I have no problem virtualizing large scale databases but if I need 8 quad core processors to support the workload then I have to ask, why virtualize. There are reasons besides consolidation, such as mobility, recoverability, and ease of dynnamicaly expanding and contracting allocated resources as needed. I HIGHLY recommend engaging a professional services company at least to help with the design.
Firewalls, load balancers, anything that is typically hardware with dedicated ASICs. These virtual appliances typically are very taxing to your virtual infrastructure and cost about the same as the physical box. Also, iSeries, but I'm pretty sure I could do it if our admin went on vacation for once :)
Imagine coming up from a stone cold shutdown. What would be a super thing to have? How about DNS and DHCP? AD too if that's your thing. Some nice little box that can wake up your LAN in 5 minutes so you can start troubleshooting the boot storm as the rest of your VMs try to start up and all get stuck in the doorway like the Three Stooges.
I've done it on modern hardware. it's WAY too slow, and gets to the point that backups take longer than 24hrs when the database grows. Then it gets very disruptive. To manage I offloaded the mailbox store role to a real machine running a second copy. Left the first one only checking for spam and as a client hub that outlook machines and the outside world connect to.
Acquiring and using sockets is high overhead for the VM and can become a bottleneck. We ran an experiment on virtualizing our cache servers, and with fairly identical specs the real machines had 25-50% better throughput when the machine was under load.
If you're going to virtualize something that gets a lot of traffic then it makes sense to scale up the server and environment.
If you're talking about virtualizing an enterprise scale server/server farm then you'll want a solution that is designed to handle that sort of situation.
As some people said, shared disk doesn't make I/O happy. That's a key point which is dealt with in enterprise scale virtualization by spreading the load across many different systems. So the hit of shared load is mitigated by access to multiple systems with redundant information. There are some very cool products that do this sort of thing very well.
But generally it's a bad idea to shoe horn an enterprise system into a limited virtualized environment where performance will suffer.
You don't want to virtualize unless you're consolidating servers. The costs just don't make sense. Where you save the money is when you get three servers to do the work of 10... or 10 to do the work of 100.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Virtual sex is just not the same.
You would hurt things by attempting to virtualize an HPC (High Performance Computing) environment. It's all about raw horsepower, and you sacrifice a chunk of that in a VM environment.
Depending on the environment and the available assets to the IT Department.
As an example:
Assume you have VMWare ESXi 5 running on 3 hosts with a vCenter and a combined pool of say 192GB of RAM, 5TB of disk, 3x1Gbps for NAS/SAN/iSCSI and 3x1Gbps for Data/connectivity.
It would become unwise in such an environment (without funds to expand it) to run any system that causes a bottleneck on your environment and thus decrease performance for other systems. This can be:
- Systems with High Disk load such as heavy DB usage or SNMP Traps or Log collection or Backup Storage Servers;
- Systems with High Network usage such as SNMP, Streaming services or E-mail;
- Systems with High RAM usage.
For this example, any of the above utilizing say 15% of your total resources for a single instance server would ultimately become cheaper to run on physical hardware. That is, until your environment can bring that utilization number down to 5% or is warranted/needed/desired for some reason.
In my environment, we have a total of 15 ESXi v5 hosts on Cisco UCS Blades with 1TB of RAM and 30TB of Disk on 10GbE. We do however refrain from deploying:
- Media Streaming servers
- Backup Servers
- SNMP/Log Collection Servers
Hope this helps!
Virtual machine hosts. We put a virtual machine in your virtual machine so you could virtualize while you are virtualizing.
The advantages of virtualization are too great to not do it whenever possible.
The only limiting factor is, really, is how much money you have to spend on your virtualization infrastructure. VMWare's licensing got a little nutty, and SAN storage got really pricy last year.
But it's worth it. Once you have a nice VMWare cluster running, SO many things become easier. And some things that were damn near impossible before become simple.
That said, you probably want to keep at least one domain controller and one DNS server as physical boxes. Makes maintenance of the VMs easier, if you ever have to reboot the whole thing.
Just don't virtualize everything into a single host. Have multiple hosts and set the virtualization management to fail over. Otherwise losing one server means losing all the servers. Then only make enough VMs so that if one host failed, things would just run slightly annoyingly slow on the one picking up the load until the problem is fixed. Of course, don't let the annoyingly slow happen to anything mission critical with tight response requirements no matter what.
You can actually virtualize a whole lot of things. The real key is to put a lot of money into the virtualization hosts. CPUs/cores, ram, a really good storage system.
For the small budget, you can get by on a lot less.
I have virtualized several entire development stacks (app servers, DB servers, storage servers, reporting servers). {But you trade a bit of performance for a reduced physical server count (10 or 15 to 1? A pretty good tradeoff if done right)}
You CAN virtualize SQL servers. Most business DB servers at the small shop end are fairly light load (like finance systems) and virtualize well. {But if performance makes you money (ie: you have a SAAS product - then stay physical }
You CAN virtualize an entire Cognos stack (it is made up of many servers depending on how complex your environment is). {However, IBM is correct that in a heavy BI workload environment deserves physical servers. I run over 18,000 reports a day on my produciton stack. Not going to virtualize that any time soon.}
You CAN virtualize entire profit generating websites. {As long as you keep an eye on host CPU and perceived performance at the end user level}
You can virtualize a lot of this in relatively small environments.
But.. Everyone here who has said it is correct: DISK IO is a major contention point. If you stuff all of your virtual machines inside one single giant data store (VMWare term for a single large disk partition) and expect super fast performance 100% of the time, then you will be greatly disappointed. One of my own stacks would grind to very intollerable performance levels whenever someone restored a database to the virtualized DB server. We moved that DB server virtual machine's disk load onto dedicated drives while leaving the machine itself virtiaulize, and all those problems went away.
Do not virtualize anything thar requires multiple CPUs (cores) to operate efficently. SQL Server is an example fo something that works better with multiple CPUs at its beck and call. In virtualization though, getting all the CPU requests to line up into one availabe window bogs the whole virtual machine down (jsut the VM, not the host). If your workload can't survive on a single virtual CPU, or two at most (single core each), then you are best to keep it on a physical server.
Time sensative systems and high compute workload processes are also ideally to be left out of virtualization. Except.. If you can put a beefy enough box under them, then you might get away with it and not notice a performance impact.
The biggest mistake made when going into virtualization (besides not planning for your DISK IO needs) seems to be over provisioning too many virtual machines on a host. This is a dark trap if you are lucky to have the money to build out a high availability virtualization cluster. You spread you load across your nodes in the cluster. Then one day one goes off line and that workload moves to another node. If you only have two nodes, and one is already over subscribed, suddenly the surviving node is way over its head and everything suffers until you get in and start throttling non esscential workloads down.
So, what do you not virtualize? Anything where performance is critical to its acceptance and succcess. Anything that a performance drop can cost you money or customers. (Remember that internal users are also customers).
Plan ahead ALOT. If you feel like your not going in the right direction, pay for a consultant to come in and help design the solution Even if it is only for a few hours. (No. I am not a consultant. Not for hire.)
I work for a telco and we've virtualized a lot of stuff, including telephone switches. We ran into a lot of problems with things that required reliable clock/syncing. 2 way video, voice, television, etc... using virtualized services on a VM machine doesn't seem to work very well either. So if you're using SAS or other cloud based stuff and your users on a virtual machine you run into all sorts of weird transient issues. Lastly, it may seem silly, but if you're company is anything like mine, you have a lot of people that have built their own little tools using Microsoft Access. We didn't realize just how many MS Access tools were out there and how important they were to some departments until we put them on virtual machines and found out that the MS Jet database is a file system based database and definitely does not work well with virtualization... so bad in fact that in many cases it corrupted the database beyond repair. We even tried moving some of the more important ones over to Oracle backends (because frankly, if they're important they should've been all along) but even MS Accesses front end couldn't deal with the virtualization... even though it was an improvement. We finally ended up having all these micro-projects where we had to put all these custom made tools, many of them made by people that didn't know what they were doing and didn't even work for us anymore intro real DBs with real web-based frontends. Reverse engineering some of those was a nightmare. It's a can of worms we likely wouldn't have opened if we had the foresight. I'd personally like to see MS Access treated just like Visual Studio in that only IS is allowed access to it... but I don't make the rules so... whatever.
at my 250k employee company with a bajillion servers and workstations, virtualization is mostly a work-around for the ancient and technophobic company policy of seperating servers by the individual application they run. All of my department's server side stuff (except the database) can easily be run on one box with one active/active failover box in a different location. This is how it was demo'd, benchmarked, vetted, and tested. Corporate audit went ape shit that we had an APPLICATION SERVER that was also SERVING UP WEB CONTENT!!!!!!!!! Fast forward 8 years and we have THIRTY TWO virtual servers in EACH ENVIRONMENT (production and fail-over). All doing the job of one decent server, and realistically all together taking up one server's worth of hardware (but with much more OS overhead BS than just using the one stupid server for the various applications.
So basically we pay some VMWare licenses, 62 extra windows licenses, some hefty maintenence contracts, and who knows what else in order to use the server in the way that the software originally was intended to run (1 box for all the apps). Nice workaround for braindead company policy.
Honestly, other heavily virtualized shops that I have seen were mostly the same thing.
Virtualization in the business world is really just a work around for the fact that computers got more powerful faster than they were able to gain trust and confidence of senior management.
Virtualization is a stone-age technology, useful for crippling hostile environments. This is why "cloud" providers love it, and developers use it for testing. Incompetent sysadmins use it in hope that they can revert their mistakes by switching to pre-fuckup images, having this strange fantasy that this shit is going to fly in a production environment.
If you REALLY need separate hosts for separate applications in production environment (what you almost certainly don't in presence of package manager and usable backup system), there is host partitioning -- VServer, OpenVZ, LXC-based environments, up to schroot-based chroot environments.
Contrary to the popular belief, there indeed is no God.
There are a few "workloads" that just don't like to be virtualized for one reason or another.
Active Directory Domain Controllers -- these work better now under hypervisors, but older versions had a wonderful error message when starting up from a snapshot rollback: "Recovered using an unsupported method", which then resulted in a dead DC that would refuse to do anything until it was restored from a "supported" backup, usually tape. I used to put big "DO NOT SNAPSHOT" warnings on DCs, or even block snapshots with ACLs.
Time-rollback -- Some applications just can't take even a small roll-back in the system clock very well. These have problems when moved from host-to-host with a technology like vMotion. It's usually a coding error, where the system clock is used to "order" transactions, instead of using an incrementing transaction ID counter.
DRM -- lots of apps use hardware-integrated copy protection, like dongles. Some of them can be "made to work" using hardware pass-through, but then you lose the biggest virtualization benefit of being able to migrate VMs around during the day without outages.
Network Latency -- this is a "last but certainly not least". Some badly written applications are very sensitive to network latency because of the use of excessively chatty protocols. Examples are TFTP, reading SQL data row-by-row using cursors, or badly designed RPC protocols that enumerate big lists one item at a time over the wire. Most hypervisors add something like 20-100 microseconds for every packet, and then there are the overheads of context switches, cache thrashing, etc... You can end up with the application performance plummeting, despite faster CPUs and more RAM. I had one case where an application went from taking about an hour to run a report to something like five hours. The arithmetic is simple: Every microsecond of additional latency adds a full second of time per million network round-trips. I've seen applications that do ten billion round-trips to complete a process!
Although most things are no brainers like you mentioned in your post, I'd say my best advice is: Don't guess and do analysis. Clearly you invested into virtualization for a reason and not just because you convinced your boss it was the 'trendy' thing to do. I'm glad to see you're not picking random systems because some poser sys-admin who makes bullshit conjectures said it was a good idea.
On the Windows side, there's plenty of tools to use to gauge virtualization candidacy; I've mostly used perfmon and cross-referenced it with my current performance on VMFS storage luns and what CPU/memory resources I have to spare in what resource pools are available. Linux (which is my primary line of expertise), IMHO, is much easier to gauge. You've got sar, iostat, vmstat (heck the whole sysstat pkg for that matter), not to mention if are a GUI trending fanboi, you've got xymon, nagios, cacti, big brother, etc. to graphically trend performance with nice rrd-tool graphs.
Also, my other factor is your line of business, where your datacenter is and annual budget towards technology update/refresh.
Is the Antichrist. Or the uncle-christ. Or something. Anyway it's damned slow.
Please do not read this sig. Thank you.
What happened to http://slashdot.org/palm site? Since May 29th, it's not being updated. The last post I see is "TomTom Flames OpenStreetMap"...
Other than a few niches the whole VM thing is solutions to problems that are supposed to be solved by a well engineered OS and software. Both of those are not done that well so we see visualization as a solution.
Me, I would put multiple services on 1 server with a redundant one or whatever. Especially related services where 1 does not work if the other is offline or they can benefit from local host communication. Where I'd look to visualization is these lock-in programs you get stuck with that break anytime to touch anything and lack features the VM would safely add to them. Having racks of specialized servers that are idle much of the time is wasteful; therefore, being able to consolidate them without software conflicts (system crashes included) is extremely useful. I'd not be keen on virtualizing a busy server either. VM adds significant overhead and sometimes that is worth it and other times it is not (keep in mind labor always costs and hardware gets cheaper.)
What bugs the hell out of me is how our OS designs are fussing in all the wrong areas. We could use some fundamental changes with old ideas borrowed from Multics or additional hardware memory protection like the mainframes which kept drivers in another memory space. More standardized drivers, like how USB has class drivers (the system bus is evolving into a network...) How about better abstraction so I don't have to recompile everything when something changes or some library update breaks a bunch of software... Why did it take decades for me to have out-of-the-box support per-application access to system calls and network ports? chroot was always horrible.
It's also very useful for testing, development, prototyping. What better way to have a vast variety of platforms for these tasks?
For prototyping your metal-based services, you can purchase a roomful of servers or you can install vmware. Which is gonna get you to production within your budget?
Unless you write all of your own software, you are going to have old legacy applications in your system, whether you like it or not. If these applications are not CPU intensive but they are still necessary, virtualization is an ideal solution.
You could use blade servers. Use a few blades as virtual hosts for most servers and the other blades as database and high performance servers. After the initial investment for the chassis, each blade is ridiculously cheap. And it cuts down on network gear
I wouldn't virtualize our delivery truck. That's be bad.
Oh, and our stores' inventory. That'd be bad virtualized, too.
I don't respond to AC's.
Whether or not you virtualize a given workload, you need to manage its resource usage. In the trivial case, you can see your CPU used up by some other program unless you provide your program a guarantee of enough CPU for the actual number of users who will be employing it.
Ditto memory, disk and networ I/O, bus bandwidth, etc, etc.
A more surprising case is putting two workloads together that formerly worked properly on an older, slower machine. If you increase the amount of a critical resource, both programs under load will start using more of every resource. For example, a batch job that got 30% more CPU increased the amount of disk I/O it did by several times. An interactive program on the same machine was rendered almost completely unusable because it couldn't do the I/O it needed. The customer in that case thought the vendor was lying about the speed of the machine, and demanded his old one back.
Linux is a hotbed of resource management experimentation, so you can statically size and configure a program (workload) to be able to withstand a given load. Commercial Unixes have good enough controls to do most common cases. I can't speak about Windows and BSD, as I've not researched them (yet). Mainframes, not surprisingly, have the best controls for what in their days were exceedingly precious resources.
If your OS doesn't have good resource controls, or if you don't know how to use them well, you'll end up splitting up the virtual machines onto a undesirably large number of physical machines, just in order to do the management the hard way.
The difficulty, by the way, varies as something like the square of the number of machines and the resources used, so virtualization and consolidation is easy for well-behaved, small and unimportant programs, and can be evil for anything that turns out to be big, resource-intensive or important. Think of that as a lemma used to derive Murphy's law (:-)).
--dave
davecb@spamcop.net
Comment removed based on user account deletion
I had a job where you would have to connect to a virtual desktop for actual work. The local operating system of the computer you were actually using was only for connecting to the virtual one. It was a horrible experience and very frustrating. Please never force others to work like that.
Isn't it funny how two people can look at the exact same computing setup...
One person says "hardware is cheap so we give the users maximal control"
The other says "what a terrible waste of resources"
The hardware costs you speak of are ZIP ZERO NADA compared to potential profits.
I wouldn't virtualize a firewall.
-Z
What possible reason is there for doing this??? Oracle spends much time and effort on their product's features, just so you don't have to resort to this sort of thing.
There are plenty of valid reasons for virtualization but running a database server is not one of them, esp. if you are complaining about performance.
Specifically, I hear that it's generally not a good idea to virtualize Asterisk servers that you expect will be handling more than 12-15 simultaneous connections. However, at the moment I've got three Asterisk servers that are shouldering lighter loads and running just fine on qemu-kvm virtual machines.
There are various "virtualisation" technologies out there. I guess it depends on how you define "virtualise". To me it means more than just "VMware". There's partitioning/dynamic domains (Sun E25k, M9000, etc..) where CPU/memory and I/O boards within a single physical unit are defined as machines. Then you've got paravirtualised systems such as IBM LPAR's or Sun LDom's (sorry, but "Oracle VM Server for SPARC" just sucks as a name). Then there's Solaris zones and BSD Jails. All these schemes are low latency and work fine for heavy workloads that may struggle under VMware.
That including VoIP, video-conferencing, online game servers and anything realtime.
If such services exist, the firewall too should not be virtualized.
As dumb as this sounds, there are still many software vendors who will not support their software on virtual platforms. Any of those programs are likely candidates to remain non-virtualized...or during pricing negotiations play hardball with them and drop the names of competitive products which do support virtual platforms and watch them squirm until they give in (I've seen that happen twice!).
Only other things I'd consider to not virtualize are any programs/systems with specific disk and/or I/O requirements. For example, depending your SAN infrastructure, you may have higher latency than you would with DAS in RAID-10. Or anything that would take a massive chunk out of your SAN and you're concerned about available space. A good example for that would be an Exchange 2010 environment with 5000 mailboxes (1GB each) and you want to have a database availability group with three total database servers - that's 15TB. Plus the fact that with Exchange 2010 has been designed to utilize JBoD disks (even plain ol' SATA), it's probably easier all the way around to keep those ones physical.
I read some folks post things about time-sensitive servers/services. I cannot comment on the validity of those claims, as I have never run into them, but I always kept my NTP server (usually the PDC-Emulator in AD) as a physical server. Otherwise, I'd recommend virtualizing anything any everything, save for one DC and whatever server/service you have that is doing your network management/SMNP.
Something often overlooked is security critical guests/data. Even though hypervisors are quite lean they are no replacement for a real, physical barrier. At least be very careful about what you mix.
As for overhead it depends on virtualization type. For example the shared-kernel, namespaced approach carries very minimal overhead but you pay some in security and flexibility.
For your standard x86 hypervisor virtualization (vmware, kvm, xen, hyperv) there's a few problem areas still.
* Timekeeping ("wall clock" is largely solved, it is the higher resolution stuff that can bite you)
* Realtime support (well d'oh)
* Guest SMP and memory (RAM) throughput is not very efficient. Overheads in this area is can be a real buzzkill.
So I generally avoid anything timing critical (NTP servers, high time resolution monitoring, poorly written systems prone to timing related races), workloads requiring more than a couple of cores for a single guest, and anything that does high throughput use of memory (which may or may not include busy databases depending on access patterns).
Including the servers. No need for any hardware at all. It's VMs all the way down.
Or maybe you could just virtualize the CIO.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
It's all work that needs to be done anyway.
"people who run Windows do not care about performance. Or security. Or reliability. "
Yeah they might be FACTORY WORKERS or DOCTORS or LAWYERS running an INDUSTRY-SPECIFIC APPLICATION.
You know, the people who actually EARN the money that pays IT's salary.
You can't virtualize timekeeping. No matter how much my boss says so. Stratum 1? No. Stratum 2? Nope. Stratum 3? Yeah, barely.
This didn't matter so much until the virtualized servers on multiple continents started having clock skew so large that they were bumping into Kerberos ticket timeouts.
And ... have you ever tried to synchronize logs of a multiple-point-of-contact intrusion attempt when the systems' virtual clocks don't tick at the same rate? Heh.
I've had to deal with the virtualization of building automation servers that handle hundred building sized campuses. The performance loss is... significant.
The whole article is worded as though written by an advertiser. This is nothing but Slashdot Market Research. Either it will be a hit business article, "What Not to Try and Virtualize, Straight from the Engineers" or research into how segments of the industry can convince you to virtualize that anyway.
Must be nice, buy one website and you end up with a corralled group of wise and experienced IT gurus. Then slaughter them like sheep. This post was nothing but Market Research. Move along.
You don't need all your LDAP and/or other Auth, DNS, and other core services on physical hardware, but make sure that if your whole virt environment goes down you can get it back up again...
I run a radio station's tech. We could virtualise our website and a few things like email, Nagios, etc, but anything that touches a sound card or needs to operate at low latencies/realtime (even soft RT), not a chance. Gotta be bare metal.
I see loads of comments that I agree with about vm best practices, but I'll add this generalization:
It sounds like you have a small-ish setup. Virtualization is a little different when you get below a certain size, because you don't have the budget to throw at it. My last project took some 150 servers into 15 physical machines. Lots and lots of purpose-specific servers running some little app or service alongside the normal big servers handling file serving, print serving and enterprise apps. The 15 machines were beefy, but they were the cheap part. The storage was the thing. We blew over a quarter million on a nice SAN to go with the two we already had. With high-end storage you can do just about anything you want with virtualization. In fact, lots of things will suddenly perform much better due to the time-sharing of better hardware. Well, and the network. It turns out you need a lot of fast and well managed ports to run a VMware farm.
We got huge benefits from virtualizing DEV, QA and Staging environments. They were always way, way underpowered and cramped before virtualization. Also, we were able to rip off copies of anything we needed to experiment with in seconds. Huge, huge benefit there. And not just from the server virtualization - there's a lot of network hardware that we never would have been able to afford that just gets virtualized. In DEV and QA we routinely ripped off copies of a whole suite of related servers and stuck them in their own private network just to try something out - something you could never do with physical hardware.
Anyway, if you can afford the hardware you need for servers and storage and network - virtualize everything that doesn't have a good reason not to be virtualized. Ideally set up server farms in two locations and use SAN and VMware features to keep instant-on copies of everything in two locations. It takes a bit of work and more than a tiny bit of cash, but you'll be bulletproof when you are finished. Actually, I don't want to underplay the work involved in full redundancy - it isn't just VMware, there's work to be done at every level, particularly at the network level. But once it is set up correctly, your workload drops precipitously. A VM farm will be much, much less work to maintain than the physical servers - and your users will perceive a noticeable uptick in reliability. With a correctly sized and architected farm you'll never have downtime due to hardware problems again. This is a powerful argument for forcing everything you can possibly justify into virtualization.
We had a few reluctant business units and a couple of vendors that wouldn't certify their stuff on VMware (this was 2005-2008 era), so we kept the old hardware server updated and ready to go as a bailout plan and virtualized them one at a time. Never had a problem, everything worked better on VMware. The desktop project on the other hand... well, don't get me started...
So in other words, if the use case falls within the parameters you've set out, and you can manage to get some help from someone who knows what they are doing, then virtualization can be a big win for you.
And then you push HARD on the straw man: "the biggest virtualization benefit of being able to migrate VMs around during the day without outages."
but there are PLENTY of other reasons that are perfectly valid! There are plenty of good use cases for virtual machines where it's just fine if the virtual machine stays right where it is.
But don't let me stop you from making overblown, over-generalized pronouncements
when virtualization is used in engineering organization, i've yet to run into an organization that orders the appropriate hardware. and what has occurred in every situation is, we end up trashing. when instead we can go to fry's or call dell and get a few $1,000 machines. my advice is don't go whole-encildada, 9 yards, or hog. but to create an environment that works in both standalone, and virtualized.
I know.. I sound like a open source geek.. but really.. check it.
For instance, you can run Oracle Standard Edition on up to 2 physical CPU's. However, according to Oracle, you must count EACH physical CPU in the server its running on (unless, of course, you are using Oracle VM, which is the only exception they allow, I know.. surprising).
If you put Your oracle DB on a VMWare server running with 4 CPUs'... congratulations, you now need to upgrade to enterprise edition. (and easily at least one more zero in the price, since now you also have to license every core, and feature)
What are we going to do tonight Brain?
breast!
Remote sysloggers :)
Firewalls
Visualisation hosts
I have seen some amazing digital art but a painting you touch and view as a lone artifact is far superior than digital art. Take the cave paintings of Lascaux as a prime example or a pure artifact.
Is the "VM" on an 80-core z/OS host or what?
Okay, I've seen lots of talk about typical data center and IT type stuff (SQL servers, DNS servers, AD, etc), but what about High Performance Compute Farms?
I've been battling our IT department for over a year now because engineering is getting Virtualization shoved down our throats. We have a farm full of high end servers for doing ASIC and FPGA engineering work: synthesis, simulation, static timing, verification. We use farm software to manage jobs, licenses, and resources. But all of the jobs are both CPU demanding (every process and every thread pretty much pegs each core to 100% usage), and extremely RAM heavy, both in size (50-100GB) and bandwidth required. Fortunately, not so IO intensive, but some jobs do have to write out GBs of data files, but generally it's a very small percentage of the total job runtime. We have jobs that take more than a week to run on X5690s @3.47GHz with 128GB of RAM. Even a 10% performance hit has drastic effects when spread over 1,000s of jobs.
In every VM scenario, our job performance suffers when compared with bare-metal. Even more so when they do stupid things like configure an HP G7 (dual processor X5690, 2-way NUMA box with 6 cores per processor/NUMA region) as a 16-way single processor SMP machine (yes, 16 cpus, not 12, so 4 of those cores don't even really exist). The VM was setup with 128GB of RAM, the box physically has 96GB. Not surprisingly, the performance sucks, we can't even determine which real cores the jobs are running on, whether we are having memory performance issues between NUMA nodes (the guest OS kernel thinks the box is SMP), etc. I don't think even the guest OS kernel knows when it's swapping RAM to disk. At least on bare-metal, we could improve performance further with things like taskset and numactl. Inside a VM, those tools appear to be worthless.
Despite our best arguments to the contrary, it seems VMs "are required", even though for a high-performance compute farm I can't see any benefit to virtualization. Each box in the farm had a maxed out CPU load before the virtualztion - the farm software does the load balancing between servers already. We could do all the optimization in the world in the VMs, but the performance will only asymptotically approach a bare-metal configuration.
Am I nuts? Isn't something like a high-end compute farm for ASIC engineering something that _shouldn't_ be virtualized? How does one make a case to IT that some workloads, such as 100% CPU / RAM bound engineering jobs, do NOT benefit from Virtualization? It seems to be the latest "buzz", but just like the "cloud", it's not peaches & cream for everyone or every scenario.
It could be worse I suppose. For a brief moment, IT suggested we outsource our compute farm to the cloud. I was pretty much speechless.
'cause if you knock it offline by accident, your easiest tool with which to bring it back online is gone?
Ditto with the online manuals for the virtualizer.
This problem was described in 1961, in a short story by Hal Draper titled: MS Fnd in a Lbry.
Kind of like how it's a bad idea to mess with a host's eth0 settings if you're currently logged in via ssh through eth0.
Or putting a breakpoint in the debugger's breakpoint handling routine. Or single-stepping into the debugger.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
By the way: This is one of the things that's a problem with systems (like lisp and smalltalk) where the development environment is part of the program under development, rather than a separate toolset which treats the target code as pure data.
Modifying the environment itself can be a major hassle. And it breaks isolation when developing something intended to stand alone, dragging in a lot of unrelated code.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
There's still some software (*cough* IBM *cough* Oracle *cough*) that is sold on a per-core basis. While some have tools to measure aggregate usage in a Vm farm, the reality is that they a) always round up the number of cores in use and b) mean installing a separate tool infrastructure just to track usage.
In a small shop this probably isn't a problem. In an enterprise, I found myself on the wrong end of a multi-million-dollar audit because our server boyz decided they wanted to virtualize everything, and didn't care what was running on the old hardware -- or how it was licensed.
While we're getting very close to very interesting virtual experiences, my garden remains one thing that I would not virtualize.
Things I would not Virtualize:
1) Email of any Kind
I think this is obvious. If it isn't your stupid.
2) File Services
If you don't have access to your files, work stops. If someone else steals your files, your work stops and you might go out of business.
Cloud is notorious for not backing up data.
3) Virus Detection
There has been rumors. Symantec, and large virus providers have been cooperating with authorities and the FEDS to specifically not detect certain viruses that are being written by these organizations.
Use local, open source virus checkers on _your_ equipment.
4) Scheduling
I don't like people knowing my schedule.
5) VoIP
I don't like my stuff being bugged.
6) Web Browsing/Services of any kind
I don't like people recording my web links to target advertising. It isn't healthy for a free market.
Things I would virtualize:
1) Educational Materials/Teaching Facilities/Training.
2) Technological and Materials related to Science/Mathematics. Library sciences
3) Complete records of who and what every Politician talks to and where every dollar they get on a minute, by minute basis.
-Hack
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
old (romanian) joke:
"dad, what does virtual mean?
son, go ask your mom if she would sleep with our neighbor.
mom, dad said to ask if you would sleep with our neighbor.
why 2@!##!, what kind of a woman do you two think i am?
dad, she says she won't.
okay, now ask her if she would sleep with our neighbor for a grand.
mom, dad says to ask you if you would sleep with our neighbor for a thousand bucks.
well..... i might.
dad, she says she might.
okay, now go ask your sister if she would sleep with our neighbor.
see son, virtually we would have two grand, in reality we have two whores."
Shared disk does not make I/O happy. -- Working...
It would probably not be a good idea to run all your vCenter instances virtualized, nor all the Active Directory instances. If you do backups of the virtual machines themselves, I'd not recommend putting the backup system in the virtual farm, either ;-)
Basically, any ressource you need access to in order to manage, troubleshoot and recover your virtual farm should not rely on it.
I wouldn't virtualize my house.
Anything realtime.
We deliver realtime control systems and two things we never do is virtualization and 'puting it in the cloud'. We need the PLC to have an answer within 100msecs or capacity will go down.
-- The Internet is a too slow way of doing things, you'd never do without it.
Make sure you back your VM's up regularly, whatever way you do it, and keep these backups OFF the physical box. I had a situation where one of my physical boxes had a hard drive failure, and I lost half my VM's. Now they ALL have raid 1 drives, but backups should still be kept off the box.
hth
I am thé oracle server. ask me a question, and i Will try m'y best to répond you, to be of good help to you. Thank slashdot for hosting this idéal.
If the machine to virtualize on is more expensive than than the hardware things are coming from, you might not weant to virtualise. There is a little overhead, most important for I/O and bandwidth, so these you should look at.
Our experience is, that in many cases SAN allocation is handled with a forklift, giving you first available space, instead of analysing disk load, and allocate spindles to the purpose. So SAN often will give a negative impact to your performance due to the SAN people not being up to the job.
If you understand this question:
"PCIE SSDs are advertised to deliver 100,000 to 500,000 IOPs. Has anyone experimented with PCI-Express based SSD solutions in their VM hosts to keep high IO VMs like VDI and SQL from swamping their SAN infrastructure?"
you are a computer expert.
We suffer more in our imagination than in reality. - Seneca
Virtualize Everything at first, things that fail should be researched for what in the infrastructure is causing the failure. If a quick solution isn't found, pull those VMs back to physical boxes.
This isn't a complete failure, just a learning opportunity. Eventually even cheap infra will support virtualizing everything.
The main reasons to virtualize still make up for all the downsides:
* flexibility
* lower costs (provided you avoid VMware and MS-Windows)
* increased utilization
* better management
* lower power, cooling issues
Where I work, we limit the VM density to until 80% hostOS utilization and can migrate them to other physical servers with little effort. Not all are on SAN storage, even those that aren't, can be moved pretty easily. RAID and excellent backups have saved us a few times, but those would have been needed on non-virtual infra.
A little late to the party, but I'd say backups.
You want access to your backups, no matter what the state of your virtualization infrastructure.
The monitoring system.
But I would hesitate to run more than one VM per physical machine in most cases. And in any case, I have vmware PLAYER blow up on me and cause problems all the time, I don't really trust vmware to run a bunch of machines on one host. I've known too many people who have worked for vmware.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
We'll never virtualize our BOFH.
cpghost at Cordula's Web.
A current topic of debate at work is whether or not Virtualized Machines (VM) can be reliably used for performance testing. Specifically, can VMs be used to host LoadRunner test software to generate load against the targeted test system? The current answer seems to be that virtualization is an acceptable host in a single tenant model where the host server is dedicated to performance testing and is not over-subscribed.
You can virtualize just about any service you want, if you have good servers to run them on. At my shop we have 260 servers on 13 VMware servers and have almost no performance problems.
But there is a catch:
In order to get any kind of redundancy, you will need shared disks, meaning a SAN. We have spent about $100,000 on servers and about $500,000 on the SAN. But on this environment the only things we don't virtualize are services that we are needed to boot the VMware environment and the backups. We even have scientific number crunching server as VMs.
Nuff said.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
But how about you know what you're doing ? Failing that, make sure you have 2 hosts in the same vlan. Fucking up eth0 beyond the point where you can, if you know what you're doing, connect from a host in the same LAN is quite hard.
...I'll let you figure out why, suffice to say that I've seen someone try it, fully believing they were somehow gaining CPU cycles... oh how we laughed!
You can virtualize a lot of stuff in the data center. Some of it brings high return on investment and others don't. You want to do a needs analysis on existing infrastructure and expected resource level commitments over the medium and long term.
Then what you'll find is that you should definitely not virtualize your underpants. Underpants should definitely stay in the realm of the non-virtual, and preferably right there on your asset.
The rest of the stuff? Meh.
If this were Usenet, I'd killfile the lot of you.
Anything that requires a lot of dedicated RAM and fills it's allotment up regardless (such as databases and good file servers will cache).
I actually don't virtualize anything server-side because where I work is small enough that it will actually cost more. We do use chroot'ed environments for DNS, Apache etc but they all run on the same host, there is actually little that virtualizing would do for us (besides giving me more machines to patch/configure).
What is good to virtualize is any Windows environment, I give my clients their Windows environments virtually, it saves me a lot of time and they can always jump back easily if they screw up. The only things we need on Windows are very specific scripts and software that's only used once in a while.
Custom electronics and digital signage for your business: www.evcircuits.com
If you're looking for a performance hike by binding a thread to a CPU using taskset or ThreadAffinity, you'll want to steer well clear of any kind of VM. In fact, if you're seeking any performance benefit by controlling what happens on the metal, VM is going to make that impossible.
The latest offering from IBM scales to 300 virtualized servers (on a z114 in the cheapest config, realisticly @ $100K). Redundancy is built in the hardware. CRC is done at the hardware level. Mind you, these systems are designed to run at 100% utilization non-stop. Not this if higher than 15% you should run physical c(r)ap from VMware.
The best weapon of a dictatorship is secrecy, but the best weapon of a democracy should be the weapon of openness.
If there is some technical reason you wouldn't virtualize such as trying to avoid shared disk IO, afraid to put "all the eggs in one basket", etc., then you have not thought hard enough or are not willing to spend enough money. Think clusters of VMs with shared storage on big-assed SANs.
Ive seen a couple companies have a problem where the whole underlying fabric of their VM architecture render them broken for almost a week. During this time none of their VMs were accessible. My advise is if there is one thing your company just cant live without, dont put that in your VM cloud. One example would be PBX software. If you live and die by your phones, then having them on a separate independent system with its own built in redundancies will do more to ensure some level of survivability during a disaster.
Anything that requires promiscuous mode or low level access to the network drivers. The extra layer of virtualization and the generic VM network drivers prevents this type of access.
Anything that would take up all of the resources for any of the key system components (i.e. CPU, Disk I/O, Network I/O). Some examples of these would usually be Database servers, Backup master servers, etc.
Ask Slashdot: What Type of Asset Would You Not Virtualize?
^^^ That, I wouldn't virtualize (or at least I would think over it very seriously.)
boobies should never be virtualized
End-user workstations. $300 disposable desktops are barely more expensive than "thin clients" and, in a proper shop, take no longer to swap out.
Everything can be put on 1 big box. That Box cannot be directly connected to the Internet.
willy
There's 3 types of Private Virtualization:
Single-Hypervisor on Host: E.G. the cheap 2K8R2 AD server that runs 1 2k8R2 VM. This strategy is useful for backing up and is usually used on servers that have high security, backwards compatibility, or strange hardware needs (e.g. DRM key or telecoms kit). It can also be used for DB Servers (since some server configs can be quite complex and quite undocumented) if you don't mind the overhead.
Multiple-Hypervisor on Host: E.G. The 2, 60K/Apiece 8 processor, 64 memory module behemoth with it's own dedicated redundant PSU, UPS, SAN, Fibre switches, etc. This strategy is useful for taking 50 servers that are taking up 5 racks at $100k/year of data center space, $150k per year of per-processor software licensing $50k/year of hardware replacement cost and turning that into 1 rack at $12k/year and $25k/year of per-processor licensing and 20k/year of hardware replacement cost.
Clustered Hypervisor on Multiple Hosts: HA-Version of the Multiple Hypervisor on a host, but this is usually used to consolidate a multisite 5 Nine's config or by providers who want to provide IAAS Services.
All companies start with single hypervisor, move onto multiple-hypervisor, and graduate to the clustered environment.
You DO NOT put AD on a on Multi-Hypervisor or Clustered Hypervisor environment; those get their own, dedicated, super cheap web server-type systems.
You DO NOT put basic network services (DHCP, DNS, etc) on Multi-Hypervisor or Clustered Hypervisor.
You DO NOT put the critical business app server on a Single Hypervisor system then "restore" it to yesterday when the motherboard fails on that system.
You DO NOT deploy 10 single-hypervisor DB Servers then connect them all to a SAN; you deploy a clustered Hypervisor environment and deploy 10 VM's, and you assingn VM's different resource pools at different points in the day and work with your DB Staff to do the DB Processing at the proper times. This way you can break up jobs across 10 machines at the cost of a half a machine of performance.
this is an excellent breakdown.
DRM: Terminator crops for your mind!
We had a SAN go down. Took out roughly 20 servers. BAD day!
I would advise keeping your DHCP / DNS / and at least a replica of whatever directory system you use (Active Directory / E-Directory / LDAP) on their own iron or you my find yourself without a working net - even if it's just one host having issues.
We are using Citrix Xenserver and have over 300 vms. Our network / routers / switches / dns aren't virtualized (the world is heading in that direction too), but everything else is including email, database servers, app servers, web servers, etc. We have our physical servers connected to our SAN via iSCSI. No major issues in over 3 years. I can snapshot a production environment and spin up a dev / test version in minutes whereas before, this operation would take days presuming you even had a server available. Virtualization is awesome.
We have a build farm using both optimized NFS and SAN-base filesystems. The SAN is a lot faster than the NFS but also far more expensive. However, local disk is far faster than both of them but makes it hard to do virtual machine failover.
I would dearly love to have a physical cluster of machines for building on (a single build takes roughly 20 hours on our build farm) but the IT gods have decreed that the build farm SHALL be virtualized.
There are always compromises. You just have to figure out what is most important to you. If your goal is 100% virtualization, then you are going to have to be more diligent about designing, planning, and maintaining the environment. If you are not the only person who will be responsible for the environment, you have to make sure that you put in a solution that whoever else is touching the environment can support as well - one well-meaning, but improperly-informed person can do a lot of damage in even the best-planned environment.
Personally, I would always leave at least one physical server for AD/DNS (which I would give the PDC Emulator role, since it's a fairly resource intensive one and you're likely to have plenty of spare cycles on the physical server).
As long as your environment isn't especially complex, you will probably be better off virtualizing vCenter. However, depending on your environment, there may be justification for keeping vCenter physical.
I like to have some kind of monitoring platform that is physical - it's never good to have a catastrophic failure that you don't get notified of because your monitoring software was one of the affected VMs, or your mail server VM was down and the alerts didn't make it to you (or you can virtualize your monitoring platform, and have something physical that monitors your monitoring platform - possibly something with a SMS gateway, which frequently only seem to work right with physical servers anyways). Generally, you can put this on either your physical AD/DNS server, or you vCenter server if you have one.
Any server that relies on any specific hardware to operate is certainly not a virtualization candidate, unless the vendor has a solution. Fax servers (typically requiring fax boards), servers with hardware dongles for licensing (although, sometimes you can use USB or Serial over IP devices to work around this limitation), etc.
Any highly performant database server (especially if clustered) deserves a second look before virtualizing. Not that it can't be done, but there can be an awful lot of suffering if you don't get it right the first time.
Any software vendor with whom you have support contracts should be consulted before virtualizing the corresponding server - some simply refuse to support their products when virtualized. Sometimes you can lie about it and still get support, but some of them will remote in and check for VMware services, processes, etc and not provide support if they are found.
Anything with high system requirements is not a great candidate for virtualization. One of the major selling points is taking ten servers that average 5% CPU and combining them onto a single host to realize cost savings over having to replace those 10 physical servers at some point.
If you have a quad cpu db server then you're likely going to have to dedicate a host to run that single VM, so you're still paying the same hardware costs, adding in VM software costs, and slightly reducing the performance by introducing the overhead of a hypervisor.
Other problems are systems that have specialized hardware, i.e. something that you have to connect to a serial port. That doesn't work well in a virtualized environment.
My preference is always to keep the system running backups on a separate physical server. Reason for this is 1) the backup server should not be so critical as to impact your production apps if there is a problem with it, 2) restoring from a VM catastrophe is a lot easier if you don't need the VM infrastructure to work to perform a restore, 3) it's a lot easier to throw a server and a tape drive in your trunk if you need to run to escape some sort of disaster than it is to throw multiple VM hosts, SAN, etc in there, and 4) I prefer not to share bus bandwidths with running VMs when running backups.