Linux – Better performance – Running Windows 7 VM with Linux Host, or vice versa

Caveat: the following is based on my subjective observations, rather than proper objective testing.

Disk I/O for some load patterns are going to be at the top end of your 10-20% bracket, perhaps a little higher, but not near the 50% you state. You can mitigate the I/O hit a number of ways, including:

• Giving the VM plenty of RAM for the OS to use as cache (this means the host machine having plenty of RAM of course otherwise it will starve and start swapping both itself and the VM)
• Tell the VM manager not to let any RAM allocated to the VM swap if it can possibly help it
• Make sure the VM hosts temporary storage in RAM by having /tmp and similar mounted as tmpfs filesystems.
• Make a good choice of on-disk filesystems and related tweaks in the VM. If all the code and compiler output is held elsewhere too, i.e. in source control and backups, then do away with journalling to reduce writing activity. Also if your filesystem is ext2/3/4 use the noatime option if your build process is fine with this (most, if not all, are) or relatime if noatime is not possible (most distributions now default to relatime, I think).
• Similarly, if your code and output is safely copied elsewhere, tell your VM manager that it is OK to buffer writes to the VM's vdisks.
• If you don't feel safe with the riskier options above (possible delayed write caching, no FS journals) you can tweak your build process to use RAM for temporary storage, by making it use that tmpfs mounted /tmp as much as possible.
• Have the VM's vdisks on a separate drive if you can, that way if it does need to perform a sizeable chunk of I/O operations it won't be competing as much with the host OS and other VMs.
• Make sure the VM is using fixed-size virtual disks. Growable disks increase the IO performance hit, sometimes considerably.

The I/O hit is going to dwarf any CPU hit somewhat, though there is some performance drop here, too. Unlike I/O though, there is very little you can do about it. With a modern CPU and a virtualisation product that can take advantage of the CPU's explicit virtualisation support the difference for completely CPU bound operations should be no more than a couple of percent. Try to avoid virtual SMP - this can actually be slower than giving the VM a single vCPU because of the way physical CPU time gets scheduled. In VMWare at least a guest with 2 vCPUs must wait until two cores are free in order to get a time-slice from the host scheduler - if the host is under load on top of the VM this can make quite a difference and if the task(s) are mainly CPU bound and can be split appropriately you will often be better off running two or more VMs (assuming you have the RAM to support this) instead of giving one VM multiple vCPUs.

The use pattern you state (constant compile cycles) will be impacted by these performance hits, but I expect you will lose a lot less time this way than you would with the inconvenience of dual-booting. If your Windows use is much less CPU and I/O intensive, i.e. just using office apps and not heavy DB work or gaming or the like, you might want to consider running Linux as the host and Windows in the VM.

You need a name resolution server of some sort.

First setup a DNS server that accepts dynamic updates on one machine that has a static IP. BIND is the obvious choice (installs on Windows and Linux) but there are other Linux versions that work just as well such as DJBDNS etc... Your DNS server will need to forward requests to your ISP's DNS server or to some other public DNS server. A good domain name that should be safe enough to use is "home.internal" No need to register it and it is not a public domain... This machine you set DNS onto will need to be up all the time...

Once that is setup, tell your reouter's DHCP server to hand out the IP of the DNS server you just setup.