Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

What is the purpose of a physical standalone server Vs a server which hosts several logical servers?

I am from a development background and constantly build sever client - server systems. However, I never delve into the physical aspects....

Often, I will point a web service to a database application via an IP address, i.e. the address at which the the database application lies.....

Now this notion of Physical Vs Virtual has been bugging me - am I pointing to a virtual server or a physical one? Do physical servers have a particular purpose - i.e. just for storage etc or are they also used in practise to host applications?

share|improve this question
add comment

3 Answers

Well, the VMs have to run on something, right?

More seriously though, quite often server loads are greater than what a VM can handle, and you need one or more systems to handle it. VMs are great when you have many, lightly loaded applications. When you have something that needs a little more grunt, it makes sense to actually have a server doing the job. Even where the server is not fully utlilised, well, you have room to grow.

As for the second part of your question I'd borrow from and refer you to SE's own architecture

Its a lot of servers - there's dedicated ones that serve up the databases (and backups for those), there's multiple web servers (and backups), there's load balancers, all working in unison to ensure that things run fast. So, yes, there's application servers, backup servers, and load balancers, all of which are set up to do specific jobs. Even with shared hosting or VMs, you'd have different systems doing different jobs - storage, web servers, databases, hosts and so on. Its probably unusual to have a general purpose machines outside smaller workplaces or development/testing/home server setups

From the user/dev (and in this case, the developer is the user) perspective though, the difference between a VM and a physical machine running properly is very vague. Its just a machine, and you use it the same way you would a physical system. The advantage with VMs of course is consolidation (you can run many VMs on a single machine), and the ability to adjust to loads if you suddenly need to adjust to higher traffic. Physical machines are better if you have the need for a fairly large infrastructure setup and can dedicate one or more machines to a role.

share|improve this answer
add comment

The trivial answer is "yes, physical servers are required, if only to host all those virtual servers". But I suspect you're asking "why would anyone pick physical over virtual, or vice-versa".

Funny you should ask. I just agonised about whether to virtualise my colo'ed box, and in the end decided against it. The pros were obvious: it's cheaper, more flexible, someone else looks after the hardware, I get virtualised "console" access rather than having to pay for IP-based KVM (or drive to the colo), and so on.

In the end, I decided to stay physical.

The first hard reason was that I wanted to use a USB device called an Entropy Key to inflate my server's entropy pool. I know that most virtualisation technologies do permit physical (USB) devices to be routed through to a particular VPS, but it's not a standard feature of most virtualisation packages.

The second hard reason was that I wanted a degree of control over who's on my hardware that I can't get with virtualisation. Physical access is always an issue, but my colo's pretty physically secure, has cameras all over the DC floor, and so on: it would be hard even for an employee to access it and leave no trace. If he's simply sitting on the dom0 hardware, he can watch everything my server does, and quite possible leave no footprint. What can I say, I'm paranoid.

The final reason was that I can be very clear about what my constraints are. I know how much bandwidth my discs have, because they're mine, not a supposedly-reserved channel on some over-allocated backplane. Similarly, my memory's mine, I paid for it, and it's all there when my kernel wants it.

I suppose in the end it comes down to control versus convenience. If you prefer the former, stay physical; if you prefer the latter, virtualise.

share|improve this answer
KVM has a paravirtualized RNG (Linux-only, I think) which lets virtual machines take entropy from the host. So the host could run the Entropy Key and all the VMs could take advantage of it. –  Michael Hampton Nov 21 '13 at 17:48
Fair point. I still like control, though, so I'm still on physical on that box. Virtualised nearly everything else in the infrastructure, though. –  MadHatter Nov 21 '13 at 18:01
add comment

Well, in addition to what been already told, i want to add that physical servers is still overall better then virtual in hosting heavy-load applications with high hard-drive utilization - databases and clustered computing systems (including getting popular NoSQL distributive databases). Mostly because virtual servers usually have problems utilizing RAID (especially Hyper-V systems). However with virtual machines you will usually get slightly easier deployment and high-availability as machines could be migrated from one physical box to other with no or a little configuration changes. VM's also works pretty well with hosting firewall boxes and terminal servers / remote apps as you usually want those be kept on separate machine for security or performance reasons.

So, in the very end my answer will be follow: if you interested in hosting client applications, VM's are way to go, they will give you good redundancy, scalability and load-balancing. But for server side, physical machines might be a better idea, in this way it would be way easier to manage and maintain it, as you would have one less layer of software to care about (this comes from my personal experience: trying to troubleshoot performance issues on virtual SQL server is really, really painful).

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.