1

We are looking into virtualizing our C++ Build server(s).

The main reason being that our current toolchain that we use in addition to the build itself in Visual Studio only runs properly on Windows XP (or 2003Server), and the secondary reason being administrative ease (just clone an image and be ready to run on a different HW.

In the end, the setup would/should most probably be one VM per hardware box, because sharing hardware just doesn't make sense for a C++ build, because it will max out CPU and disk anyway.

A colleague has done some preliminary tests on his developer workstation, and they're just horrible:

He measured the following build times for a full build of our Visual C++ 8 (Visual Studio 2005) solution:

  • Desktop/Native with Windows 7 : ~16 min
  • Vmware Workstation with virtual disk, guest is Windows XP : ~1h21min (500% !!!)
  • Vmware WS with direct access to a dedicated physical disk and limited to 4 cores : ~42min (260% !!)

With these timings, we certainly won't go virtual!

We're now asking ourselves whether we made any wrong assumptions with our measurements.

  • Did we mess up any settings to get such horrible slowdown for the C++ build?
  • Should we have tested ESX(i)(?) instead of Workstation?
  • Should we expect anything else from MS Hyper-V? (Because our IT would prefer that.)

Related questions that did not really fully help:

Community
  • 1
Martin
  • 563
  • 4
  • 10
  • 25

3 Answers3

2

Did we mess up any settings to get such horrible slowdown for the C++ build?

Probably not, VMWare Workstation wasn't the right tool for the job.

Should we have tested ESX(i)(?) instead of Workstation?

Yes, it'll be better than Workstation, still slower than bare-metal but much better.

Should we expect anything else from MS Hyper-V? (Because our IT would prefer that.)

If you want, performance is broadly comparable to ESXi, some things are quicker, some slower - feel free to give it a try.

Chopper3
  • 100,240
  • 9
  • 106
  • 238
  • 1
    Hyper-V wont work RIGHT NOW because it limits you to 4 virtual cores. Hyper-V vv-next (octover) moves the limit to 32. Anything requiring a lot of cores can not run in Hyper-V at the time being. Even 32 stretches it likely by the time it is out. – TomTom Mar 26 '12 at 09:31
  • Tip my hat to you TT, I'm no HV expert - well spotted. – Chopper3 Mar 26 '12 at 09:41
  • Running into this all the time at the moment. Heck, you can not even simulate a mid range processor these days :) I really look forward to more power full vm's. – TomTom Mar 26 '12 at 09:44
0

What do the performance stats (Perfmon, Performance Monitor, etc( inside the guest say it's bottlenecked on? What does the hypervisor OS say for equivalent stats?

Are you using paravirtualised drivers or emulated ones?

Does the PC you're testing on have the IO virtualisation extensions as well as the basic virt acceleration? Are they BIOS enabled?

Rodger
  • 609
  • 4
  • 6
  • "Does the PC you're testing on have the IO virtualisation extensions as well as the basic virt acceleration" - is that a hardware thing, or a OS/driver thing? – Martin Mar 26 '12 at 09:28
  • likely both. Special drivers, but some stuff needs hardware support for full efficiency. – TomTom Mar 26 '12 at 09:32
  • Make sure hardware virtualisation (Hyper-V, H-VT, Vanderpool, whatever it is called) is enabled in the Bios of the host machine. Most vendors turn it OFF as factory default. (Lenovo, HP, Dell all do this last time I checked.) Makes a big difference. Virtualisation is slower but 500% is real bad. We run C++ builds in similar setups and typically suffer less than 200% slowdown compared to native hardware (and we run on virtuals HD's as well). – Tonny Mar 26 '12 at 10:37
  • xp won't virtualize worth a damn on hyper-v, AMD does have a driver that fixes the issue if your host is amd based. I don't think intel has a fix. So if you can use win7 instead. – tony roth Mar 26 '12 at 14:13
  • for some reason it won't let me edit my comment, with win7 as a guest I'd suspect you double your performance. – tony roth Mar 26 '12 at 14:15
0

Virtualization is not always a fit... but... you haven't told us any specs on the developer workstation. How much memory does it have? How many cores?

Are you running compilation with the /MP flag?

Were the VMs configured to overcommit on memory? Did the memory balloon driver ever kick in? What else was running on the host OS? (For example, did your test VMs have antivirus software running, as well as the host workstation?)

I definitely would have done your testing on ESXi - the hypervisor is extremely efficient, and will provide much better performance as a host for your VMs. But you still have to contend with memory and CPU commitment.

Mike
  • 101
  • "But you still have to contend with memory and CPU" - there will be no contention. At the moment we have decided that should we go virtual (tests for Hyper-V and ESXi still outstanding), we will run one VM per physical hardware. – Martin Mar 30 '12 at 18:06