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:

Improve this question

3 Answers 3

Reset to default
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.

Improve this answer
3
  • 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, 2012 at 9:31
  • Tip my hat to you TT, I'm no HV expert - well spotted.
    – Chopper3
    Mar 26, 2012 at 9: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, 2012 at 9: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?

Improve this answer
5
  • "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, 2012 at 9:28
  • likely both. Special drivers, but some stuff needs hardware support for full efficiency.
    – TomTom
    Mar 26, 2012 at 9: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, 2012 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, 2012 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, 2012 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.

Improve this answer
1
  • "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, 2012 at 18:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .