Back in the Windows XP days, I discovered that running Windows in a VMWare VM, hosted on Linux, was faster than running the same version of Windows bare on the same machine.
I never came up with a good explanation for that.
replies(1):
I never came up with a good explanation for that.
Disk cache, to be precise.
I'm not sure how true that is, because in the Windows XP days most of us wouldn't have had enough RAM to spare to do that.
Depending on the VM technology they use they offer a variety of different caching mode and configurations, but the basic three approaches that most everybody offers are going to be something like;
"writeback" means that when the guest's storage data ends up in the host's cache it is reported back to the guest as 'written'. This means that from the guest's perspective the disk is written to, but in actuality the data is still floating around in memory. If the guest wants data to be 'safe' they need to issue additional flush commands.
"writethrough" means that the host is using its memory for caching file system, but that writes are reported as 'competed' only when they have been committed to actual disk.
and "none" means the cache is used as little as possible.
So if your guest's virtual disk is in 'writeback' mode it isn't actually writing to real disk. It is writing to memory. Which is going to be very fast up to the point were the cache on the host is exhausted.
Certainly Windows could lie to applications and not write information to disk and keep it in memory much longer then it normally would but that would defeat some of the assurances that file systems are supposed to offer to applications.
'writeback' would be closer to what Windows already implements on the OS level, but because Linux is just plain faster it should improve performance somewhat. Microsoft can only work in improving the performance of Windows to get the same results, but Linux is pretty hard to beat.
'none' is what I use when running Linux on Linux because having two layers of cache is just kinda wasteful and doesn't result in real improved performance.
Pretty much. Just speculating because I don't know how your systems was configured back in the day.
But all of what I said applies to most VM solutions.
If you are dealing with enterprise-grade hardware it isn't a bad things. Keep in mind that typically OSes are going to assume that they are the only things operating on storage. So if you have like 30 windows boxes all trying to write to shared disk at the same time it can lead to some bad behavior if you are not using a write cache.
The system has battery backup and typically they expect you to use shared SAN or NAS with multipath and/or bonded network interfaces for redundancy as well as having backups. So the chances of data loss is a lot less then typical consumer hardware and it gives the hosting OS better chances at optimizing and scheduling writes properly.
Also remember the guest OS still has the option to send a 'flush' command to disk, which would ensure the writes complete regardless.
> It's been many years, but I don't imagine I would have chosen an option like that. I am very surprised VMWare would default to such behavior.
This is pretty normal. You'll see the same sort of options with hardware RAID devices and such things with their own internal battery-backed cache.