Can someone from VMware please comment on the question of whether "forced unit access" (FUA) is implemented within ESX Server or the virtual SCSI drivers.
There was a discussion regarding this topic:
But the question was not answered.
I ask for the same reason as the original thread was started.
Considerations when hosting Active Directory domain controller in virtual hosting environments
That is probably the only interesting point raised in the document..
This has benn banded arround for a while..
The really odd thing is (except maybe for that point) is that every single point is valid whether Virtual or Physical...
All of those points exists if you Stay Physical..
They are not the result of Virtualization, we deal with them every day thanks to Microshaft own poor design...
I'll make an attempt to comment with respect to ESX3. Since people might be expecting an official statement, lemme just clarify the attempt is my own, and not my employer's.
ESX3 and past generations of ESX do not cache guest OS writes. This gives an ESX VM the same crash consistency as a physical machine: i.e. a write that was issued by the guest OS and acknowledged as successful by the hypervisor is guaranteed to be on disk at the time of acknowledgement. In other words, there is no write cache on ESX to talk about, and so disabling it is moot. So thats one thing out of our way.
Moving on, the KB seems to suggest that on a physical machine, the device you are using should support FUA so that the device's write cache can be disabled. Consider the following:
\- If you disable write cache to a LUN in a diskarray, performance drops like a rock. For eg, see slides 42, 43, 44 in one of our VMworld 2005 presentation http://download3.vmware.com/vmworld/2005/pac092-b.pdf. This is true of both physical and virtual machines. Give it a shot.
\- All respectable (read, server-class) disk controllers, especially the ones ESX supports, have NVRAM based write caches. That means writes are not lost even on a server crash, and they eventually make it to disk. Further, the write caches are battery or aux power supply based, so that even if the server loses power, writes are flushed to disk using aux power.
In light of the above, a recommendation to disable controller write cache looks outdated.
Inspite of the above, if ESX were to pass FUA command to the underlying disk controller, it would cause the controller to disable write cache for the entire physical LUN. The VM that caused this is just using a virtual disk, which is a small fraction of the big physical LUN. So all other VMs that host their files on the same VMFS volume will suffer from abysmal write performance needlessly. Most importantly, it will break an important guarantee ESX gives you: that VMs run in isolation. So in conclusion, I don't forsee ESX passing FUA commands from a VM to a disk that contains a VMFS volume.
That leaves us with the possibility of using the VM with an RDM. In this case, FUA will indeed be passed to the underlying disk, and the hardware is free to do whatever it wants with it -- disable write cache, laugh at you, whatever.
In conclusion, I feel that the KB article is interesting but outdated with respect to the capabilities of current hardware.
PS: I haven't been able to log on to the community forums very often of late, so I might not be around to answer any responses to this post.
I think you misunderstood much of the article. Some of it does point out issues that are there whether you're dealing with a physical machine or virtual, but that is only to point out that just because you have two virtual machines does not mean you have redundancy, for example. You have to consider the host machines as well.
Furthermore regarding your comments about Forced Unit Access and write cache, FUA is a bit that is enabled or disabled during the write operation. When this is enabled the write is not returned as successful until it is physically written to disk. When disabled the write is written to cache and then returned as successful before written to cache. If the VMWare's SCSI emulator does not support this and write caching is on, all writes will be cached for everything regardless of what the guest OS wants to happen. In this scenario, you risk serious corruption in the event of a power failure unless write cache is turned off for everything. (The guest OS will think writes have happened successfully, when they in fact never happened.)
If it does support FUA, then the guest can tell the disk system to not return a write as successful until it is physically written, and there is no need to turn off write cache for everything.
Are you saying VMWare will not install on systems that do not use NVRAM for cached writes?
Even if that were true, NVRAM might help in many power outage cases; if it doesn't get fried during the power outage or whatever. Having had experience with EMC failures, you are still taking a risk if you think that telling the OS the write is complete before it actually is can be made bullet proof. Whenever you do this, you trade risk for performance. NVRAM does not negate the risk because the risk is inherant in the design as soon as you're design includes telling the OS the write was completed before it actually was.
In the rare instance of a problem, you can't be sure when the problems would be discovered from an AD perspective once you get into the situation. Maybe you can recover, and maybe you can't. For some people risking the integrity of your entire authentication system may be a bit too big of a risk. For others it may not be a big deal.
The article is not dated. These are extremely important issues whether you like Microsoft or not.
According to VMware, FUA is supported on VMware. Here's reply from VMware technical support:
Sent: 24. februar 2010 11:25
To: (Jakob Fabritius Nørregaard)
Subject: Re: VMware Support Request SR# 1490632591
Please do not change the subject line of this email if you wish to
Forced Unit Access is supported by VMware. A large number of customer's have virtualized Domain Controllers which is evident in the community forums.
Thanks & Best Regards
Technical Support Engineer
VMware Global Support Services
VMware Technical Support Knowledge Base