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 I'd like to do is buy a server to be used for testing purposes only. I'd like to be able to restore virtual servers from backups to the test machine, and then run a few client VMs on the machine to test configuration changes on the server instances. Thus I'll be able to test my backup/restore process on a regular basis, and also try out configuration changes before going live.

I'm wondering if I need to spec my test server equal to or greater than the largest VM I'll be testing? That is, if I have a VM configured to see 8 processors and 16GB of RAM, does my test server need to be able to provide it with that much power?

It seems like I should be able to spec it lower since the VMs won't be doing nearly as much work. They would, however, see fewer hardware resources when booting up.

Edit: in other words, when restoring a VM to the test machine, I would have to reconfigure it for fewer resources prior to booting it up.

share|improve this question

2 Answers 2

up vote 1 down vote accepted

If all you want to do is test the things you describe then I would recommend that you don't waste your money on matching the test server's CPU spec to your production environment. I wouldn't cut corners too much on RAM if your application is likely to actually try to make any use of it - you can configure a VM on most platforms with more virtual RAM than the amount of physical RAM available but as steven mentions in the above comment the hypervisor will just use disk swap for that and if the VM tries to use it performance will tank catastrophically. On any systems I've tried this on adding or removing vCPU's has no negative effect beyond reducing performance.

As far as testing config changes before you go live this is a slightly different scenario. If you are just looking for compatibility issues then there's no real problem but if you are likely to be testing performance tweaks then you should try to make sure that the test platform is a reasonable match for the performance characteristics of the production. Reasonable may still mean 2x or 3x lower spec, just make sure you don't try to test things like storage performance tweaks on a system with 2 local SATA drives and expect that similar changes to have similar effects on a production system using an 8Gig FC SAN with 60 15k FC drives.

share|improve this answer
    
Good points. I will only be testing to make sure things don't break, not for performance. –  Boden Jan 12 '10 at 22:29
    
what virtualization tools allow you to assign more RAM to one VM than is on the physical server? –  warren Jan 13 '10 at 14:27
    
ESX for starters, to confirm this I've just set up a VM with 64GB RAM on an old test ESX 3.5 cluster which has three Hosts with 4GB RAM each. It's possible, just not really useful. –  Helvick Jan 13 '10 at 15:08

You cannot assign more CPUs to any given VM than you have physical Cores. Nor can you assign more RAM than you have.

share|improve this answer
    
Indeed. But an isolated server VM isn't doing much work, hence my question. –  Boden Jan 12 '10 at 16:49
    
if you're running the VM that wants 8 CPUs on a quad-core machine, it won't work. However, if you have 20 single-CPU VMs running on a quad-core box, it's fine –  warren Jan 12 '10 at 16:58
    
What if I modify the VM prior to booting it? What happens when Windows server suddenly sees half the cores it was expecting? –  Boden Jan 12 '10 at 17:26
    
unless the application cares about missing CPUs, I've never seen a problem with CPUs being added or removed from VMs - it's just like removing them from a real server –  warren Jan 12 '10 at 19:13
    
You can assign more ram... it'll hit swap/page but that is completely unwanted. –  monksy Jan 12 '10 at 19:14

Your Answer

 
discard

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.