7 Responses

  1. Bobby Fantast1c
    Bobby Fantast1c at |

    This is one of the changes that doesn’t get much press but caused a lot of deliberation in the admin world.

    Couldn’t even begin to tell you all of the wasted meeting discussing proper block sizing.

  2. James Kilby
    James Kilby at |

    a misunderstanding of this really burned me back in the days of 3.5. We havent yet upgraded to 5 our clusters are still 4.1 but we will run into this as ours are all 4mb block

  3. CLEB
    CLEB at |

    I took the opportunity to migrate our Exchange mailbox VM’s to VMFS5 Datastores after the 5.0U1 upgrade.
    The majority of our other datastores are 1MB but migrating them to new LUNs with VMFS5 gives us the opportunity to do some other array housekeeping too.

  4. Ben Loveday
    Ben Loveday at |

    Hi Chris,

    Great article! I’ve seen this exact same thing in our dev lab when storage vmotioning VMs from an older VMFS5 cluster that had been upgraded from v3 to a newer VMFS5 one, even when the storage subsystems both support VAAI. Having the block sizes matched make quite a remarkable difference 🙂


    1. Brian
      Brian at |

      One advantage of keeping one vmfs3 LUN about is that the older a motion engIne can re-thIn your thinly provisioned disks when moving datastores. I haven’t seen this happen with new VMFS5 volumes due to the standard block size. So it doesn’t hurt to keep one legacy volume kicking about just in case 🙂

  5. Newsletter: January 18, 2014 | Notes from MWhite

    […] increase the time it takes to do SvMotion’s.  Great article for us and it is found here.  BTW, I think we saw similar issues way in the past, not with SvMotion, but in other ways when we […]

  6. VMFS 5 – Unified Block Size | Data Recovery Newstand

    […] interesting piece, “Increasing Storage vMotion Performance with Unified VMFS Block Size” by Chris Wahl, illustrates why having a unified block size on VMFS volumes is important for […]

Share your point of view!