Support for Exchange Databases running within VMDKs on NFS datastores RRS feed

  • General discussion

  • The virtualization community are asking Microsoft to change their support position for Exchange Server running in VMDKs on NFS datastores. Support is long overdue.  

    The virtualized SCSI stack, including initiators and disks inside of a VM, are unaware of the underlying storage protocol that provides data connectivity between a hypervisor and storage device. Support is long overdue and the rationale for the lack of support is not recognized by the storage industry.

    The following co-authors (from 7 different vendors & 2 solution integrators) are aiming to work together for the good of our customers and the community too raise awareness of this issue in the hopes that Microsoft will reconsider the support policy.

    Josh Odgers (@josh_odgers)

    Senior Solutions & Performance Engineer @ Nutanix

    VMware Certified Design Expert #90 & vExpert

    Vaughn Stewart (@vStewed)

    Chief Evangelist @ Pure Storage


    Chad Sakac (@sakacc)

    SVP, Global Systems Engineering @ EMC


    Matt Liebowitz (@mattliebowitz)

    Solution Architect @ EMC

    VCP & vExpert & author of Virtualizing Microsoft Business Critical Applications on VMware vSphere

    Michael Webster (@vcdxnz001)

    Senior Solutions & Performance Engineer @ Nutanix

    VMware Certified Design Expert #66 & vExpert

    Andrew Mitchell (@amitchell01)

    Consulting Architect @ VMware

    VMware Certified Design Expert #30

    Rob Waite (@rob_waite_oz)

    Solution Architect @ Tintri

    VCP & vExpert

    Nick Howell (@that1guynick)

    vTME @ Netapp


    Chris Wahl (@ChrisWahl)

    Solution Architect @ AHEAD

    VMware Certified Design Expert #104

    Gabriel Chapman (@bacon_is_king)

    Solution Architect @ Simplivity


    VCP & vExpert

    Mahmoud Magdy

    Senior Technical Architect

    vExpert, MVP and Symantec BExpert

    The Details of Microsoft’s Position

    At present, Microsoft supports Exchange deployments on NAS, specifically only on their hypervisor and their file based protocol, SMB 3.0. The intent of our efforts is to address the gap in supporting Exchange in VMware vSphere & KVM with datastores connect via NFS 3.0.

    The support policy can be found here and is summarized below...

    The storage used by the Exchange guest machine for storage of Exchange data (for example, mailbox databases and transport queues) can be virtual storage of a fixed size (for example, fixed virtual hard disks (VHDs) in a Hyper-V environment), SCSI pass-through storage, or Internet SCSI (iSCSI) storage. Pass-through storage is storage that's configured at the host level and dedicated to one guest machine. All storage used by an Exchange guest machine for storage of Exchange data must be block-level storage because Exchange 2013 doesn't support the use of network attached storage (NAS) volumes, other than in the SMB 3.0 scenario outlined later in this topic. Also, NAS storage that's presented to the guest as block-level storage via the hypervisor isn't supported.

    Another statement of interest in the above link is as follows;

    "Configuring iSCSI storage to use an iSCSI initiator inside an Exchange guest virtual machine is supported. However, there is reduced performance in this configuration if the network stack inside a virtual machine isn't full-featured (for example, not all virtual network stacks support jumbo frames)."

    While the contributors to this post agree this is not an ideal configuration, it is not a performance issue when used with enterprise grade storage and with properly architected networking.

    The support statements is odd as there is a large portion of the VMware market that is deployed over NFS. This configuration is supported and is the preferred means of data connectivity for many. A decade ago, one could run Exchange 5.5 over NAS (CIFS). This support was removed with Exchange 2000. It appears the concerns from the Exchange 5.5. The difference with a virtualized instance is the Exchange application is NOT accessing data via NAS. All VM data access is via virtualized SCSI.

    This may be a valid (or legacy) support policy back in the days before virtualization became mainstream, and before the evolution of 10/40Gb Ethernet where performance may have been limited by 1GB connections (as opposed to the NFS protocol itself) or for deployments where NFS is presented directly into the Guest OS which we agree would not work.

    The abstraction of virtual SCSI from the underlying infrastructure (FC, DAS, iSCSI or NFS) is shown in the below diagram courtesy of http://pubs.vmware.com

    Over the years, the contributors of this community post have seen countless successful deployments of Exchange on vSphere, using both block (FC,FCoE,iSCSI) and file based storage (NFS/SMB) so why is only NFS not supported?

    There are a number of blog posts related to Exchange and NFS storage, one such example is by Tony Redmond (@12Knocksinna), titled “NFS and Exchange, Not a good combination”.

    To Tony’s credit, he goes much further than most posts we have seen, which in most cases just say “Its not supported” and give no technical justification as to why.

    Tony wrote

    One small, but terribly important issue is Exchange’s requirement that it should be able to abort a transaction should bad things happen. Block-level storage allows this to happen but file-level storage supports aborts on a best-effort basis. Simply put, without the ability for an application to signal the storage subsystem that a transaction should be aborted, you run the risk of introducing corruptions into the databases through bad transactions.”

    With a VMDK presented to Exchange, we are not aware of any reason why Exchange (or any other application) would not function exactly the same as if the VMDK was residing on a FC or iSCSI backed LUN, or if a LUN was presented to the guest OS via an In Guest iSCSI initiator.

    This is due to vSphere abstracting the underlying storage from the VM. To the operating system running within the guest the virtual hard disk appears and acts just like a local physical SCSI disk, regardless of the underlying storage protocol.

    In support of this, Microsoft has a program called “Exchange Solution Reviewed Program” or “ESRP” which Microsoft partners can use to validate Exchange solutions. This program requires specific tests including one of24 hours using Jetstress with predefined settings, to validate the subsystem not only system performance, but consistency of the database.

    Here is a Jetstress report showing the ESRP test passing with the following VM configuration with Exchange running within a VMDK on an NFS datastore

    1 x Windows 2008 VM

    1 vCPU (2.6Ghz)

    24Gb vRAM

    4 x PVSCSI Adapters

    8 x VDMKs (2 per PVSCSI)

    8 Exchange Databases (one per VMDK)

    2 DAG Copies

    The 24 Hour test can be viewed here - 24 Hour Jetstress Test

    The Databases checksum from the above 24 hour test can be viewed here - DB Checksum

    Note: The above test was ran for the purpose of this post, to show the storage abstraction works for Exchange, not to demonstrate maximum performance for the underlying storage platform.

    So if a vendor validates a VMDK on NFS implementation by successfully completing Microsoft’s official tests (via ESRP) is there any reason not to support it?

    We believe Microsoft should provide some formal process to storage vendors to certify their solutions for Exchange, in the worst case, at least allowing vendors to submit hardware for validation using Microsoft’s internal certification/QA process where these tools cannot be shared publicly.

    Please show your support for this issue by voting and leaving your constructive or encouraging feedback in the comments at the Microsoft Exchange Improvement Suggestions Forum below. This issue is already rated as the #1 issue so the more support the better!


    So to Microsoft - and too all the Microsoft Exchange & Storage experts we ask;

    1. Can you clarify by providing some form of documentation what the issue is with Exchange on NFS natively. The goal to ensure if there is an issue, its understood by the community

    2. Can you clarify by providing some form of documentation what the issue is with Exchange storage in a VDMK on an NFS datastore (where the storage is abstracted by the hypervisor). The goal again is to ensure if there is an issue, its understood by the community and can possibly be addressed in future hypervisors.

    3. If the support statement is simply outdated and needs updating, lets work together to make it happen for the good of all Microsoft’s customers, especially those who have NFS storage from one of the many vendors in the market.

    Now for those customers experiencing this issue today, lets discuss the current workarounds available if you need to comply with the current support policy and the continued impact to Microsoft customers if the policy is not updated.

    Option 1. Use in guest iSCSI initiators to present LUNs direct to the operating system


    a) Increased complexity of managing two storage protocols (NFS + iSCSI), also some vendors license features like iSCSI at additional cost, so it makes it so expensive to purchase a license on the storage just to support Exchange.

    b) Some storage solutions may not support NFS and iSCSI

    c) Increased points of failure eg: iSCSI initiator

    d) Potential for reduced storage capacity efficiency

    e) No ability for the guest to take advantage of advanced storage features that are added to the vSphere storage stack.

    Option 2. Present iSCSI LUNs to vSphere hypervisor


    a) Increased complexity of managing two storage protocols (NFS + iSCSI) and additional cost as explained above.

    b) Some storage solutions may not support NFS and iSCSI

    c) Increased points of failure eg: iSCSI initiator

    d) Potential for reduced storage capacity efficiency

    Option 3. Run Exchange on physical hardware (not virtual)


    a) Increased complexity of designing and managing another silo of compute/storage

    b) Increased datacenter requirements which lead to increased OPEX (ie: Power/Cooling/Space)

    c) Decreased ROI from physical hardware compared to virtualization

    d) Decreased storage capacity efficiency

    e) Increased CAPEX due to reduced flexibility in sizing physical hardware ie: Sizing for end state not current requirements

    f) Delayed time to market / upgrades / expansion due to procurement of hardware

    g) Increased hardware maintenance costs

    h) Increased complexity for Disaster Recovery

    It is clear based on the experience of the contributors of this article, that NFS has a large footprint in the market and for these customers using NFS, Microsoft should seek a mutual Win-Win situation for its large and small customers using NFS.

    Microsoft should extend support for NFS backed storage deployments to facilitate and simplify Exchange deployments for customers using NFS storage, which without the updated support statement would likely be forced into using multi-protocol or standalone silo type deployment for Exchange, adding complexity and resulting in increased CAPEX/OPEX.

    Let's hope Microsoft care about their customers as much as the authors of this document do!

    Tuesday, February 11, 2014 2:42 AM

All replies

  • Great writeup!

    One thing I would emphasize is even though its storage + converged infrastructure vendors leading the charge... this is an extremely frequent request from our customers, they really want Exchange + VMDK + NFS datastores to be supported by MSFT so they can virtualize Exchange in the same way they virtualize the rest of their environment.  

    Many of them also just ignore this support statement since they know there is no technical reason for it.  

    Tuesday, February 11, 2014 5:40 AM
  • Hey everyone, I hope all are well and enjoying weather that is as nice it is here in Northern CA, today. :)

    I've been working with Exchange, into the six-figure (mailbox count) range for over 15 years. After working in the field and teaching Msft (MCT), I landed at NetApp for 12+ years, where I first started working with others on an advanced storage management solution for Microsoft Exchange 5.5 (and 2xxx in the following years...). In the beginning, this was all before VSS, etc. I've seen a lot!

    I currently work at Tintri in engineering, where I am (as you may guess) focused on some exciting and innovative Microsoft integrations.

    Note: My comments are of my own personal opinion here, while working from home, juggling a few personal appointments today.

    Candidly, if I were Perry Clarke (Exchange GM) and the decision to blindly support "NFS" was an all-or-none proposition, I would decisively and with conviction say "no" <the end>. I believe that is part of the problem surrounding this topic. There is often no clear qualification in the language when people ask. It's just "NFS", foo, bar. A small PC with a 1TB SATA disk and Linux could technically yield "NFS storage"... If I were Microsoft, I would NOT want to take a support call or have a customer report a major outage (or data loss) because I had blessed such a configuration.

    Now back to reality. At Tintri, if we can deliver 100K r/w IOPS averaging a few milliseconds, power-off controllers, yank network cables, fail switches, etc. (as we do regularly, such as with our Cisco UCS qualification) with no errors, than we are clearly in an entirely different airspace. With a disruptive, irrefutably robust, industrial strength technology such as ours (I can only speak for Tintri), pushback from Microsoft can only push customers *away* from Exchange. One (of the many) reasons the Exchange team innovated so many great storage-driven features in recent years, is because SANs were too complex, expensive, etc.

    Given my long love affair with Exchange, I want to see Exchange thrive for years to come. I've been around long enough to understand how the Exchange team arrived at their disposition toward insulating Exchange from storage hiccups (it is not without reason), but times have and will continue to rapidly change. And that's not to mention the benefits of virtualization, and the automation capabilities that you simply DO NOT HAVE with bare-metal servers. Who cares if you can't put 12 cores and a jazillion GB's of RAM into a VM. That would be silly anyways, right? Multiple VMs, across multiple virtual hosts is obviously a better way to distribute the load while maximizing availability.

    Lastly, I hope Microsoft isn't betting that Enterprises will move to the cloud too quickly. The continued public-cloud volatility and the outcome and context in which it will all play out is yet to be determined, especially in the short-term.

    I can say this with confidence: Exchange works and performs brilliantly on Tintri VMstore, and we add a lot of value. Put us to the test, through any qualification process, and we will shine. I know, because I've done it myself and I am among the hardest to "impress" (so to speak).

    I have written enough (for now)!

    Warmest regards,

    Tuesday, February 11, 2014 10:06 PM
  • I can't comment on Tintri as I haven't tested it myself, but everything else you mentioned I agree with with the exception of the below 2 comments.

    "Candidly, if I were Perry Clarke (Exchange GM) and the decision to blindly support "NFS" was an all-or-none proposition, I would decisively and with conviction say "no" <the end>."

    I agree, BUT would say the same for any storage solution / protocol - so if its just NFS, the current "needs to support SCSI aborts" excuse does not fly with Exchange in a VMDK on abstracted NFS storage.

    I believe that is part of the problem surrounding this topic. There is often no clear qualification in the language when people ask. It's just "NFS", foo, bar. A small PC with a 1TB SATA disk and Linux could technically yield "NFS storage"... If I were Microsoft, I would NOT want to take a support call or have a customer report a major outage (or data loss) because I had blessed such a configuration."

    I would submit the same is true for iSCSI, any consumer grade NAS (or as you mentioned linux VM) can serve iSCSI and Microsoft support iSCSI "blindly" in the same way your saying not to "blindly" support NFS. (Which as I mentioned earlier I agree they should "blindly" support anything!)

    I have seen plenty of storage simply undersized to the point of such high latency the OS has seen high latency & even delayed write failures and similar issues - its not the fault of the FC,FCoE,iSCSI or NFS protocol though, it was simply an overloaded/undersized storage solution. But in this case,  MS would support Exchange as long as it wasn't running on NFS!?

    I think the case is simple, Microsoft should have a qualification process for all storage (as support based on a protocol which can be fully abstracted make no sense) - this would make support easier for MS, and provide more certainty for clients when deploying Exchange on a given platform, knowing it has passed the qualification tests.

    Win/Win/Win for MS , Storage Vendors & our mutual customers

    Josh Odgers - VCDX#90 Sr Solutions & Performance Engineer @ NUTANIX

    Tuesday, February 11, 2014 11:17 PM
  • Josh, thank you for pointing out that bit about iSCSI (that you could hack together a bummer "solution", and it would actually be supported). So true!

    Workload sizing correctly is very important, and it cannot be based on the size (space consumed) of the databases. I've seen the low-level storage traces as they've changed over the years with the Exchange versions, and Microsoft has made some vast improvements since the ~2000/2003 EDB versions. But all of the factors need to be evaluated together.

    Elevating ESRP testing for NFS/SMB (vhdx|vmdk(EDB)) to first-class status would be well received by everyone. But if I were Microsoft, I would try to find a clever way to discourage garage-built, hillbilly "storage systems" (or servers for that matter) in favor of real products, with real support and sound engineering so that *customers* have resources to hold accountable with any issues.

    :::I see WAG (Wild-Ass-Guess*) Engineering everywhere::::    ;)



    *Credit where it is due for that awesome term: Rob Cohee, Autodesk

    Wednesday, February 12, 2014 2:12 AM
  • After lots of feedback, I have expanded on the exact configuration being proposed to be supported in the below post.

    What does Exchange running in a VMDK on NFS datastore look like to the Guest OS?

    Josh Odgers - VCDX#90 Sr Solutions & Performance Engineer @ NUTANIX

    Thursday, February 13, 2014 11:58 PM
  • This support issue is getting plenty of interest across the industry, to the point VMware have had numerous inquires from customers about this.

    Quote "VMware has received a number of inquiries from our customers and partners about this movement"


    Josh Odgers - VCDX#90 Sr Solutions & Performance Engineer @ NUTANIX

    Friday, February 14, 2014 9:21 AM
  • Great article, thank you.
    Tuesday, March 11, 2014 3:44 PM
  • A great workaround for this outdated support policy is to stop using Exchange. There are plenty competitive products out there that do the same or a better job and are supported in this combination or even native NFS. 
    Thursday, June 5, 2014 3:19 PM
  • Excellent discussion!. I too have been struggling with this issue in our Exchange environment. I really want to get rid of physical mode RDM's ASAP. Keep up the fight!
    Friday, August 1, 2014 5:39 PM
  • Further information about Integrity of Write I/O for VMs on NFS Datastores

    Part 1 - Emulation of the SCSI Protocol

    Part 2 - Forced Unit Access (FUA) & Write Through

    Part 3 - Write Ordering

    Part 4 - Torn Writes

    Part 5 - Data Corruption 

    Josh Odgers - VCDX#90 Sr Solutions & Performance Engineer @ NUTANIX

    Wednesday, November 12, 2014 2:37 AM
  • Hi Eric,

    I would appreciate if you would share your full name and employer, since the above was your 1st post on TechNet.

    Thanks for the reply, although I think the negativity could have been left out which would have made the conversation more constructive.

    I figured I'd get the question of Nutanix Acropolis out of the way first. Acropolis Hypervisor (AHV) uses iSCSI and is certified on the Server Virtualization Validation Program (SVVP) so its fully supported for MS Exchange. Acropolis will also manage Hyper-V (running SMB 3.0) in an upcoming release so that's another supported solution on Nutanix in addition to ESXi and iSCSI which we also support.

    Regarding the article you referenced regarding VMware being sued, I'm not sure what relevance that has to the topic?

    If you and Microsoft were correct about SCSI protocol emulation on ESXi not working as per the patent, every SQL deployment on ESXi/NFS datastores would have corruptions left, right and center. This is not the case. I'm not saying corruptions never occur, but when they do its not due to SCSI protocol emulation of VMDKs on NFS datastores.

    In addition the SQL team support SQL in VMDK on NFS datastores, I've personally validated this and even wrote the below article.


    Now you may come back with NFS isn't supported for some SQL deployment types, and this is true, as old style clustering using shared disks is not supported but things like Always on Availability groups are supported.


    Coming back to what I believe is your main point around SCSI aborts and the various quotes you choose to use.

    The one you left out which is detailed in my post below is the following:

    "Accordingly, a faithful emulation of SCSI aborts and resets, where the guest OS has total control over which commands are aborted and retried can be achieved by keeping a virtual SCSI request list of outstanding requests that have been sent to the NFS server. When the response to a request comes back, an attempt is made to find a matching request in the virtual SCSI request list. If successful, the matching request is removed from the list and the result of the response is returned to the virtual machine."

    So what you quoted is true but its not the complete story, if the Virtual SCSI request exists it is dropped as you mention but a response is also sent to the virtual machine so it and the application is completely aware of what's going on, in the same way a physical system is or a virtual machine running on iSCSI/FC etc.


    So in summary: The SQL team supports VMDKs on NFS datastores, and SQL along with most applications have the same block storage requirements as the Exchange team quote including Write ordering, Forced Unit Access, Write Through (which BTW Nutanix does regardless of storage protocol) and protection from Torn I/Os.

    I don't expect we'll agree on this topic, as over the years its gone beyond technical and probably started as MS simply not wanting to help/encourage ESXi deployments but has in the last few years gone into the realm of religious debate.

    To me, I just hate it when customers are being scared into expensive capital expenditure or dedicated HW silos for one application (such as Exchange) due to FUD. Worse still the FUD being repeated (in 99% of cases) by people simply parroting what somebody else says as opposed to understanding some of the topics outlined in my blog.

    Now don't mis-interpret the above as me saying you are parroting, I have no idea if you are or not but too your credit you have gone much deeper into the conversation than most.

    Nutanix customers can chose from 3 hypervisors each of which is fully supported (by MS) using iSCSI or SMB3.0 but the purpose of the original post was about updating the support statement for all vendors, Nutanix simply took the lead in raising awareness in the community which I am happy to say has been achieved.

    My closing point, It seems crazy I can run MS Exchange in a supported config on a consumer grade NAS running iSCSI but not enterprise grade highly QA'd storage solution/s from many vendors if NFS datastores are used with ESXi.

    For such a business critical application, if it was my call, I would have a storage certification program regardless of storage protocol as plenty of block & file storage implementations vary in quality. Even some enterprise arrays don't do FUA or Write Through which the Exchange team have always insisted is required but only in the context of NFS discussions.

    Maybe a good topic would be to dive into how SMB 3.0 and VHDXs do emulation of the SCSI protocol - but that would only strengthen the case for NFS and no further evidence is required IMO.

    Again, thanks for the comment and especially for going further than the bulk of people who just parrot a version of what they have heard in the past from MS.

    Josh Odgers - VCDX#90 Sr Solutions & Performance Engineer @ NUTANIX

    Wednesday, August 12, 2015 12:47 AM
  • Josh,

    It's somewhat ironic to hear your comments on negativity when your original post amounts to a not-so-thinly veiled accusation of dirty dealings on Microsoft's part.  That said I have deleted my post and will refactor it to hopefully address your concerns.

    I will repost for another reason also.

    As you have apparently not comprehended my point about determinacy of state on data on the underlying physical media, I will attempt to explain this more clearly.

    The section of text you reposted from the patent refers to the >>virtual<< queue ONLY.

    Next you imply (by asking for my full name and employer) that my own motives are suspect.

    I'm a former engineer who has been deep into these protocols since long before Microsoft shipped Windows (or Exchange), VMware existed, and even before NFS was first used in a NAS appliance. 

    I'll let the quality of my technical analysis speak for my identity and ask (politely, for now) that you to stop trying to "out" me.  I believe that kind of behavior, in addition to being offensive in the implications it carries, can be sanctioned on TechNet.

    I will repost tonight.  Looking forward to a constructive dialog.

    • Edited by Eric_W Wednesday, August 12, 2015 1:24 PM typo
    Wednesday, August 12, 2015 1:24 PM
  • Hey guys, great discussion, but this isn't really an Exchange Development issue. I'm going to move this post over to the Exchange discussion forum on TechNet.
    Wednesday, August 12, 2015 3:22 PM
  • Hey guys, great discussion, but this isn't really an Exchange Development issue. I'm going to move this post over to the Exchange discussion forum on TechNet.

    Wednesday, August 12, 2015 4:31 PM
  • Can you name a few?
    Wednesday, August 12, 2015 4:47 PM
  • Hi Eric,

    I believe its common courtesy to introduce ones self when having a discussion, If you find "I would appreciate if you would share your full name and employer" offensive I can't help with that but I can advise nothing is implied by my question.

    I simply would like to know who I am conversing with especially since your reply may well be the first detailed discussion from a person opposing VMDK + NFS support with some knowledge on the topic. (That is a compliment BTW).

    I would also encourage you to re-submit your original post to ensure this thread has context.


    Josh Odgers - VCDX#90 Sr Solutions & Performance Engineer @ NUTANIX

    Wednesday, August 12, 2015 11:14 PM
  • Thanks Josh,

    Let me offer this.


    Please review the above first, then let's continue.

    Microsoft's statement on Exchange is (simply put) that they do not support any form of SCSI block-emulation sitting atop NFS, due to Exchange recovery mechanisms which rely on direct access to the underlying physical media.

    This makes perfect sense to me because these emulation mechanisms cannot ensure determinacy of state of the data at the LBAs on the >>physical<< device following an abort command acknowledged by a >>virtual<< queue.

    By determinancy, I mean that the state of the data on the physical disk following an aborted write >>must<< be known as either:

    (a) the original physical data was unchanged (following a successfully acknowledged abort) or

    (b) the data >>may<< have been changed (the abort was not acknowledged), or

    (c) the data >>was<< changed (the abort command returned as 'failed')

    Either way, Exchange definitely knows the state of data on the underlying physical media.

    Now if you've had a careful look at the article above, and then re-read VMware's patent that you cited, I believe you will come to the conclusion that determinacy of state of the underlying physical media becomes impossible.

    That is my own assessment and I suspect that is also Microsoft's assessment.

    Finally, my understanding is that Exchange is very much different from SQL Server in this regard.

    I can promise you that I am not a Microsoft employee, and that I have no horse in this race.  I'm just a former storage engineer who understands this problem deeply.  I support the position that >>any<< application that relies on SCSI protocols working exactly as they are defined in the T-10 specifications should take the same position Microsoft has here.

    VMware's patent text clearly implies that they are fudging the SCSI abort command and makes no attempt to hide this or state otherwise.  I believe this is because it is effectively impossible to maintain the "pass-through chain" of multiple abort commands all the way down to the physical disk queues and then the acknowledgements of those aborts all the way back up the chain to the application, once there is an NFS file-system obfuscating the I_T_L_Q relationships between block-level initiators and the block-level targets.

    This is not just VMware.  I believe that any attempt to present a block-level target that is based on underlying NFS storage necessarily 'breaks' the SCSI abort command chain in exactly the same way.

    If any virtualization vendor using NFS as an underlying data store has come up with a solution, then I believe it is incumbent on that vendor to demonstrate exactly how their implementation matches up with the Letter of the Law (the T-10 specification).

    Let me add this lastly -- consider that NFS has no equivalent command to match SCSI abort and then ask yourself 'why not'?  Once the chain of Initiator_Target_LUN_Queue nexes is broken by putting NFS in the middle, there's just no way to do it.

    Saturday, August 15, 2015 5:02 PM
  • IMO Jeff Mealiffe's comments don't align with yours as he continues to spread the word (Slide 15 of the presentation below) that Write ordering, Forced Unit Access, Write Through and protection from Torn I/Os are required for Exchange and this is exactly the same as what the SQL team require AND allow to be certified (to their credit!)

    Jeff's Presentation: http://video.ch9.ms/sessions/mec/2014/ARC305_Mealiffe.pptx

    SQL Server I/O Reliability Program Review Requirements: http://download.microsoft.com/download/F/1/E/F1ECC20C-85EE-4D73-BABA-F87200E8DBC2/SQL_Server_IO_Reliability_Program_Review_Requirements.pdf

    So Let's agree to disagree about VMDK on NFS and talk about VHDX files on SMB 3.0? What's your position here? (and i'm not interested that MS say they have tested it and its a supported config) 

    Support statement for Exchange says:

    "Also, in a virtualized environment, NAS storage that's presented to the guest as block-level storage via the hypervisor isn't supported."

    SMB 3.0 (NAS/File storage) is presented to Windows/Hyper-V which presents VHDX files as block-level storage to the guest.

    So if the Exchange teams fears about abstraction are indeed true (which they are not) SMB 3.0 with VHDX (and VMDK on NFS) should not be supported. Interestingly only a competitors solution (vSphere w/ VMDKs) isn't supported and nor can any vendor do what you suggested and demonstrate to the Exchange team how there storage works, trust me, we've tried and they are not interested in even having the discussion. 

    As I don't know who you are I can only assume you have no influence on this topic at MS, BUT If you do, I challenge you to ensure vendors are given a chance to "demonstrate exactly how their implementation matches up with the Letter of the Law" as you put it. This is all the storage/virtualization industry is asking for. Hell, the Exchange team could just give vendors the documentation of how satisfied themselves that SMB 3.0 and VHDX "matches up with the Letter of the Law" and the same tests (where applicable) could be EASILY ran on VMDK on NFS.

    (Frankly IMO, the MS Exchange team are scared of being proven wrong AND they don't want to promote vSphere deployments so they will never do this, neither reason is related to the technical implementation of SCSI protocol emulation via VMDK on NFS though)

    Me on the other hand, I would LOVE for somebody to prove that VMDK on NFS doesn't work as I have described as in theory if it didn't work properly, this would be a major challenge for all vSphere customers using NFS which I would want to help lead the resolution of.

    So there's a challenge for you if choose to accept it. If you want to contact me privately I'm sure we could arrange a Windows server on iSCSI and another on NFS for you to prove your point, or even just prove you could tell which one is which.

    Regarding your don't have a "Horse in the race" comment, neither do I. Nutanix (my employer) has iSCSI for Acropolis and vSphere and SMB 3.0 for Hyper-V all of which are fully MS supported so its not impacting our business, in fact, if anything its making us money as our Global Services team have to deploy solutions (like iSCSI in-guest) for customers when deploying Exchange which takes longer (albeit not much) than direct on VMDKs. If anything, the support statement being updated would help Nutanix competitors who in some cases don't have the multi-protocol support we do. 

    Josh Odgers - VCDX#90 Sr Solutions & Performance Engineer @ NUTANIX

    Tuesday, August 18, 2015 3:22 AM