For customers who had SATA controllers that consumed the VMware Advanced Host Controller Interface (AHCI) driver found that after upgrading to ESXi 6.5, the disk performance for those devices were significantly impacted. Basic operations such as cloning or uploading an OVF/OVA would literally double if not triple in time. In fact, I too had observed this same behavior when I had upgraded my Intel NUC (not an officially supported platform) to ESXi 6.5. One thing I had noticed at the time when others were reporting simliar issues was that their HW platforms were also not on the VMware HCL, so I was not sure if this was limited to only home-lab environments?

In any case, I and others eventually stumbled onto this blog article by Sebastian Foss who I believe may have been the first to identify a workaround which was to simply disable the new AHCI Native Driver which loads by default and forcing it fall back to using the legacy AHCI driver which made the issue go away after a reboot. Although the folks who had reported seeing simliar issue were all using hardware platforms that were not officially on the VMware HCL, I decided to still file an internal bug and hoped someone could take a look to see what was going on.

With the release of ESXi 6.5 Update 1, I am happy to report the observed performance issues with the Native AHCI driver have now been resolved! I have been running on earlier release of ESXi 6.5 Update 1 build for couple of weeks now and have not seen any of the problems I had before. For those interested, the official fix went is in version 1.0.0-37vmw or greater of the vmw_ahci driver.

You can easily verify for this by running the following ESXCLI command to retrieve the version of your vmw_ahci driver:


If you had disabled the Native AHCI driver, you will definitely want to re-enable it. You can check if its been disabled by running the following ESXCLI command and checking the second column to see if it shows "false":

esxcli system module list | grep vmw_ahci

If the Native AHCI driver is disabled as shown in the previous command, then you can re-enable it by running the following ESXCLI command:

esxcli system module set --enabled=true --module=vmw_ahci

Once you have re-enabled the driver, you will need to reboot for the changes to go into effect.

21 thoughts on “AHCI (vmw_ahci) performance issue resolved in ESXi 6.5 Update 1

  1. Afraid this did not work for me. While getting 500 MBs + read, write speeds are still at ~60MBs. ( Samsung SSD PRO 480 GB )

    Double checked the driver was updated & enabled. Re-booted the host as well.

  2. I’ve update the host to 6.5 UD1 and the module info reports. I did disable the driver before upgrading, though. Does this affect anything?

    [[email protected]:~] esxcli system module get -m vmw_ahci
    Module: vmw_ahci
    Module File: /usr/lib/vmware/vmkmod/vmw_ahci
    License: BSD
    Version: 1.0.0-32vmw.650.0.0.4564106
    Build Type: release
    Provided Namespaces:
    Required Namespaces: [email protected]_4_0_0
    Containing VIB: vmw-ahci
    VIB Acceptance Level: certified

    Michael

  3. Silly me! Pls forget my previous comment. I did only upgrade the VCSA appliance and not the ESXi host itself 😉

  4. William – This has appeared to fix my performance probs, too. I have a slightly newer version than the one you posted. Just interesting if you knew of any differences btwn the two.

    Module: vmw_ahci
    Module File: /usr/lib/vmware/vmkmod/vmw_ahci
    License: BSD
    Version: 1.0.0-39vmw.650.1.26.5969303
    Build Type: release
    Provided Namespaces:
    Required Namespaces: [email protected]_4_0_0
    Containing VIB: vmw-ahci
    VIB Acceptance Level: certified

  5. Hello!

    I downloaded this new version to test it on my HP Proliant Microserver Gen8 and the performance was not as expected.

    If I put it in RAID mode in HD 2 TB RED:

    Read: 136 and Write 78

    AHCI support

    Read: 96 and Write 48

    What’s going on?

    Thank you very much!

  6. Do we have to wait for HP to release the HP ISO image of ESXi 6.5 U1 to get this fix OR can we just update that one driver file while on ESXi 6.5.0 of the HP ISO image of ESXi?

  7. This apparently “bricked” my instance. All VMs are appearing as /vmfs/volume/* and no storage instances appear. This was due to the “trick” described by disabling the module. I re-enabled (no upgrade) and am now sitting with several VMs that won’t boot and “invisible” storage instances.

    Any suggestions?

  8. All changes with ESXi 6.,5 U1

    # esxcli system version get
    Product: VMware ESXi
    Version: 6.5.0
    Build: Releasebuild-5969303
    Update: 1
    Patch: 26

    # esxcli software vib list | grep ahci
    sata-ahci 3.0-26vmw.650.1.26.5969303 VMW VMwareCertified 2017-08-22
    vmw-ahci 1.0.0-39vmw.650.1.26.5969303 VMW VMwareCertified 2017-08-22

    # esxcli storage core path list

    (edited)

    sata.vmhba0-sata.0:5-t10.ATA_____Samsung_SSD_850_PRO_2TB_________________S3D4NX0J702488T_____
    UID: sata.vmhba0-sata.0:5-t10.ATA_____Samsung_SSD_850_PRO_2TB_________________S3D4NX0J702488T_____
    Runtime Name: vmhba0:C0:T5:L0
    Device: t10.ATA_____Samsung_SSD_850_PRO_2TB_________________S3D4NX0J702488T_____
    Device Display Name: Local ATA Disk (t10.ATA_____Samsung_SSD_850_PRO_2TB_________________S3D4NX0J702488T_____)
    Adapter: vmhba0
    Channel: 0
    Target: 5
    LUN: 0
    Plugin: NMP
    State: active
    Transport: sata
    Adapter Identifier: sata.vmhba0
    Target Identifier: sata.0:5
    Adapter Transport Details: Unavailable or path is unclaimed
    Target Transport Details: Unavailable or path is unclaimed
    Maximum IO Size: 33554432

    # esxcli system module set –enabled=false –module=”vmw_ahci”
    # reboot

    After reboot

    # esxcli system module list | grep ahci
    ahci true true
    vmw_ahci false false

    # time sh -c “dd if=/dev/zero of=test bs=16k count=640k conv=sync”
    655360+0 records in
    655360+0 records out
    real 6m 20.89s
    user 0m 0.00s
    sys 0m 0.00s

    # esxcli system module set –enabled=true –module=vmw_ahci
    #reboot

    After reboot

    # esxcli system module list | grep ahci
    ahci true true

    # time sh -c “dd if=/dev/zero of=test bs=16k count=640k conv=sync”
    655360+0 records in
    655360+0 records out
    real 5m 20.66s
    user 0m 0.00s
    sys 0m 0.00s

    • Are these figures normal ?

      on a SATA datastore I got

      [[email protected]:/vmfs/volumes/589566b4-b40e0cf2-8cac-0cc47a7c09b4] time sh -c “dd if=/dev/zero of=test bs=16k count=640k conv=sync”
      real 13m 29.23s

      • I can’t answer that, but I noticed that both of us are using a Samsung SSD Pro. Could the problems be specific to this brand/type of SSD ?

  9. Read performance is fixed, but write performance is still low with 6.5U1.
    While I can copy from and AHCI SSD or HDD to my RAID with 200 MB/s – 400 MB/s the other direction (AHCI write) is constantly 30 MB/s. No matter, if SSD or HDD.

      • I found out that the SSD I had used for testing is not good (Tanscend TS480GSSD220S). When I tried it out in my desktop machine it performed bad as well.

        After switching to another SSD everything is fine.

        CT525MX300SSD1, 500GB SSD SATA, vmw_ahci
        # time sh -c “dd if=/dev/zero of=test bs=16k count=640k conv=sync”
        real 0m 53.31s

        CT525MX300SSD1, 500GB SSD SATA, attached at SAS2108 RAID controller. Only disk cache.
        Write Through, DirectIO, No Read Ahead, Disc Cache Policy: Enable
        # time sh -c “dd if=/dev/zero of=test bs=16k count=640k conv=sync”
        real 0m 55.31s

        Still much slower than in my desktop system, but in the same system vmw_ahci is not slower than the RAID controller.

  10. Do we need to updade the vCenter server from 6.5 to 6.5 update 1, before updating the host from 6.5 to 6.5 update 1. Is there a co-relation between vCenter and ESXi build versions?

  11. FYI This does not fix the issue with RDM. The native driver (vmw_ahci) completely botches your RDM disks.

    My 8TB disks were showing up as 1.3TB, and RAW.

    Thankfully switching back to legacy ahci fixed the issue, but that was scary for a minute.

Thanks for the comment!