This Question is Answered
1 "correct" answer available (10 pts)
I can see why we are not on the same page. If VMware would provide a clear description of the functional parts of LGTOsync we would not have these issues or this discussion.
Here is how I understand the functional side of this driver.
Since ESX can not determine what the VM is doing with disk writes and memory cache at the time a snapshot is requested it cannot correctly freeze the I/O state of the vmdk for that snapshot to provide integrity of any cached SCSI operations.
VMware needed to montior this SCSI disk write and memory cache activity and feed that info back to the ESX physical hardware and complete those disk I/O operations in order to provide the integrity requirements of backup functions. They provided this capability by developing the LGTOsync driver with Legato. So when I think of the LGTOsync driver I am not looking at the VM flushing it's writes, It's the underlying host that needs to do this function. If you disable the driver you lose this capability all together. So unless you can tell me that you know for certain that the VMWare SCSI drivers support forced unit access down to the host OS then it is better to run the driver.
So I consider the following when I build VM's for AD or any DB's
http://support.microsoft.com/kb/888794
Here is how I understand the functional side of this driver.
Since ESX can not determine what the VM is doing with disk writes and memory cache at the time a snapshot is requested it cannot correctly freeze the I/O state of the vmdk for that snapshot to provide integrity of any cached SCSI operations.
VMware needed to montior this SCSI disk write and memory cache activity and feed that info back to the ESX physical hardware and complete those disk I/O operations in order to provide the integrity requirements of backup functions. They provided this capability by developing the LGTOsync driver with Legato. So when I think of the LGTOsync driver I am not looking at the VM flushing it's writes, It's the underlying host that needs to do this function. If you disable the driver you lose this capability all together. So unless you can tell me that you know for certain that the VMWare SCSI drivers support forced unit access down to the host OS then it is better to run the driver.
So I consider the following when I build VM's for AD or any DB's
http://support.microsoft.com/kb/888794
Huh, I think we're saying the same thing but comming to different conclusions
The meat of what I'm saying is that AD is simply stored in a jet database. Just like any other modern database it keeps log files of data to be commited and thus this level of data security is already partially accounted for. A partially commited DB change would still have a log present even in a circular setup and thus I consider the issue minor. Perhaps I'm unique in this area, but I've had a number of problems occur when a snapshot occurs on a DC and it has the sync driver installed. Observational data implies the entire VM is paused while the host commits vmdisk writes, simply uninstall the driver and do a snap and look at the difference in time. At least on any of my esx hosts it's easily visible, and the entire host is essentially "paused" for a few seconds.
Only VMware docs I can find that reference FUA is this one: http://www.vmware.com/files/pdf/usenix07.pdf
Still need to read through it though.
A few months ago I had a chat with a VMware pre-sales consultant. He told me that the upcoming ESX 3.5 Update 2 which is due Q3 2008 will include Volume Shadow Copy Service (VSS) support. This will hopefully eliminate any problems ESX admins are experiencing in regards to snapshots on AD vm's. I googled for VSS support and found that the Virtual Server 2.0 betas already include VSS support. Ofcourse I realize that Virtual Server is a hosted virtualization product and accesses storage in a different way than ESX does, but still you could give it a try. 
Are there any forum readers that tested VSS on Virtual Server? Were you able to snapshot an AD vm without the corruption problems on ESX that alastairc identified at the start of this forum topic?
Are there any forum readers that tested VSS on Virtual Server? Were you able to snapshot an AD vm without the corruption problems on ESX that alastairc identified at the start of this forum topic?
