Feb 12

A couple of weeks ago I posted about SQL Server running in a VM and how disk writes were assured to happen in contradiction to a poorly written article on SQL Solutions. After working with VMware Engineering there’s now a KB article that talks about how and when I/O writes happen with different VMware products. Below is the full text of the KB article. You can also find the source here.



IO crash consistency is defined as maintaining the correct order of writes in order to allow an application to restart properly from a crash. Alternately, crash consistency posits an IO acknowledged successfully to the application is available persistently on disk before any other IOs that depend on data read/written by the original IO.

IO crash consistency for any applications running inside a guest operating system varies based on the VMware product used. VMware virtualization products include VMware ESX, which uses a bare-metal or hypervisor architecture, as well as VMware Workstation, Server and Fusion, which use a hosted architecture.

VMware ESX acknowledges a write or read to a guest operating system only after that write or read is acknowledged by the hardware controller to ESX. Applications running inside virtual machines on ESX are afforded the same crash consistency guarantees as applications running on physical machines or physical disk controllers.

For hosted products, write handling depends on the host operating system.

On Linux hosts, VMware does not use unbuffered IO, because it is not safe or supported across all the Linux versions that VMware supports. So currently, VMware hosted products on Linux hosts always use buffered IO.

On Windows hosts, VMware hosted products use unbuffered IO by default.

On Mac hosts, VMware Fusion uses buffered IO by default. Mac users can change the buffering mode through the Fusion user interface by selecting Optimize for virtual machine disk performance (buffered mode) or Optimize for Mac OS application performance (unbuffered mode). Note: Mac OS X 10.5.0 through 10.5.4 cannot successfully use unbuffered mode.

When using buffered IO, VMware hosted products do not bypass the host’s buffer cache to produce crash consistent virtual machine IO. Consequently, if the IO is buffered within the host operating system, an application running inside a guest operating system on VMware hosted products might lose crash consistency.

VN:F [1.9.3_1094]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.3_1094]
Rating: +1 (from 1 vote)
How VMware Writes I/O to Disk, 5.0 out of 5 based on 1 rating

View Comments to “How VMware Writes I/O to Disk”

  1. New KB: How VMware Writes I/O to Disk - Gestalt IT Says:

    [...] Mike DiPetrillo from VMware just blogged about a new VMware knowledge base article fosuced on how VMware writes I/O to disk. This is essential reading for any VMware admin, as it deals with each OS’s I/O [...]

  2. JP Says:

    I'm thoroughly confused now. Please clarify for a simpleton like me…

    Am I correct in reading that Linux hosts (buffered I/O) are more succeptible to SQL Server db corruption? Also, does my “disable write caching” checkbox in my VMware Server's VM Disk properties have any effect on this?

  3. Mike DiPetrillo Says:

    It doesn't meant they're any more susceptible to corruption. It's just
    the way that Linux writes to disk and the way Windows writes to disk
    is very different and so we have to handle them differently. The Linux
    file system helps out a lot with the disk corruption prevention.

    And “disable write caching” shouldn't substantially change this with
    VMware Server since it's a hosted product and we're relying on the
    underlying OS anyways.

    Hope that helps.

  4. Mike DiPetrillo Says:

    It doesn't meant they're any more susceptible to corruption. It's just
    the way that Linux writes to disk and the way Windows writes to disk
    is very different and so we have to handle them differently. The Linux
    file system helps out a lot with the disk corruption prevention.

    And “disable write caching” shouldn't substantially change this with
    VMware Server since it's a hosted product and we're relying on the
    underlying OS anyways.

    Hope that helps.

Leave a Reply

blog comments powered by Disqus