WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple
You are here: Home / Nested Virtualization / Quick Tip - Increasing capacity on a Nested VSAN Datastore

Quick Tip - Increasing capacity on a Nested VSAN Datastore

03.21.2014 by William Lam // 2 Comments

The other day I needed to increase the capacity on one of my Nested VSAN Datastores as one of our users required a larger VSAN datastore than it was initially configured for. I was expecting to be able to just increase the size of the underlying VMDKs like I would for a traditional Nested ESXi environment and rescan in ESXi to pick up the new capacity without any downtime. It turns out, this is was not exactly the case for a Nested VSAN environment.

increase-capacity-nested-vsan-datastore-0
Disclaimer: Nested Virtualization is not officially supported by VMware

When you first setup VSAN, regardless of how the disks were claimed, VSAN will consume the entire device (SSD or MD). The capacity that VSAN initially detects will then be used to create the necessary partition as part of the VSAN Disk Group creation. VSAN assumes that the capacity for the underlying devices would never change as in the "real" world, disks do not auto-magically get larger 🙂 and this is a valid assumption. In a Nested ESXi environment however, it can auto-magically get larger but VSAN was not built for this use case. What ends up happening is that the underlying devices can be "hot-extended" but the existing VSAN Disk Group can not detect this new capacity.

Having said that, there are two ways you can increase your VSAN datastore:

Option 1 - If you wish to preserve your VSAN Datastore, you can hot-add additional VMDK(s) to your existing VSAN Disk Group or if it is full, you can create a new disk group and add additional VMDK(s). This will modify your setup slightly if you wanted a particular set of disk groups but will allow you to preserve your data.

Option 2 - The latter option requires the deletion and re-creation of the VSAN Datastore which is not ideal if you already have data on it. You will need to increase the capacity of the underlying VMDKs and then re-create your VSAN Datastore, but this way you can keep the existing number of disks and disk groups you initially created your Nested ESXi environment with.

In my scenario, I could not destroy the VSAN Datastore as I had someone using it and so I opted for option #1. Here is what my configuration looked like before which was a single VSAN Disk Group with 1xSSD and 1xMD:

increase-capacity-nested-vsan-datastore-1
I then added an additional 10GB VMDK to each of my Nested ESXi hosts and issue a rescan so the ESXi host would pickup the new device:

increase-capacity-nested-vsan-datastore-2
In just a few seconds, I can see my new storage device. I can now head over to the VSAN management page which is located at the vSphere Cluster and once I refresh, I can see that VSAN has automatically added the new "MD" into the existing disk group and my storage has automatically expanded!

increase-capacity-nested-vsan-datastore-3

More from my site

  • OVF template for creating Nested ESXi 3 or 32 node VSAN Cluster
  • Re: Host is in a VSAN enabled cluster but does not have VSAN service enabled
  • How to run Nested ESXi on top of a VSAN datastore?
  • A killer custom Apple Mac Mini setup running VSAN
  • Automate VSAN Observer offline mode configurations

Categories // Nested Virtualization, VSAN, vSphere 5.5 Tags // nested virtualization, VSAN, vSphere 5.5

Comments

  1. *protectedSara says

    07/03/2014 at 8:39 am

    quick tip:
    1) increase the size of the ESX's VMDKs
    2) one host at a time, enter maintenance mode, remove its disk group from vSAN and then re-add it. After that of course exit maintenance mode
    This procedure takes longer than destroying and recreating the entire vSAN but at least you can keep everything working and use the same VMDKs. HTH!

    Reply
  2. *protectedAlfonso Lopez says

    09/22/2016 at 2:55 pm

    Thank you sir. I just ran into the same issue and had to go with option 1 because I did not want to lose my existing data on the vsan datastore.
    I also happened to learn that you cannot mix Flash with non-Flash disks for the Capacity tier.

    Reply

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...