WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple
You are here: Home / Automation / Increasing disk capacity simplified with VCSA 6.0 using LVM autogrow

Increasing disk capacity simplified with VCSA 6.0 using LVM autogrow

02.10.2015 by William Lam // 20 Comments

With previous releases of the VCSA, increasing disk capacity was not a very straight forward process. Even though you could easily increase the size of the underlying VMDK while the VCSA was running, increasing the guestOS filesystem was not as seamless. In fact, the process was to add a new VMDK, format it and then copy the contents from the old disk to the new disk as detailed in VMware KB 2056764. This meant with previous releases of VCSX 5.x, you would need to incur downtime of your environment and it could be also be quite significant depending on your familiarity with the steps mentioned in the KB not to mention the time it took to copy the data.

UPDATE (12/06/16) - For VCSA 6.5 deployments, please refer to the article here as the instructions have changed since VCSA 6.0.

The reason for this unnecessary complexity is that VCSA did not take advantage of a Logical Volume Manager (LVM) for managing its disks. In VCSA 6.0, LVM is now used to make it extremely easy to increase disk capacity while the VCSA is running. VCSA 6.0 further simplifies this by separating out the various functions into their own disk partitions comprised of 11 VMDKs compared to the monolithic design in previous VCSA releases. This not only allows you to increase capacity for specific a partition but you can also now attach specific storage SLA's using VM Storage Policies on specific VMDKs such as the Database or Log VMDK for example.

In the example below, I will walk through the process of increasing the DB VMDK from the existing 10GB to 20GB while the vCenter Server is still running.

Step 1 - Verify the existing disk capacity using "df -h"

increase-vmdk-in vcsa-01
Step 2 - Increase the capacity on VMDK 6 which represents the DB partition using the vSphere Web/C# Client.

Step 3 - Once the VMDK has been increased, you will need to run the following command in the VCSA which will automatically expand any Logical Volumes that have had their Physical Volumes increased:

vpxd_servicecfg storage lvm autogrow

increase-vmdk-in vcsa-02
Step 4 - Confirm the newly added capacity has been consumed

increase-vmdk-in vcsa-03
If you would like to learn more about the different VMDK structure in the new VCSA 6.0, I will be sharing more details in a future article.

More from my site

  • Multiple VMDKs in VCSA 6.0?
  • Will I get Photon OS when I upgrade my VCSA 5.5/6.0 to VCSA 6.5?
  • How to remotely run appliancesh & other shell commands on VCSA w/o requiring SSH?
  • How to change the default ports on the vCenter Server Appliance in vSphere 6.0?
  • Which Platform Services Controller (PSC) is my vCenter Server pointing to?

Categories // Automation, VCSA, vSphere 6.0 Tags // autogrow, lvm, VCSA, vcva, vpxd_servicecfg, vSphere 6.0

Comments

  1. *protectedDingo Taz says

    04/22/2015 at 8:39 am

    Thanks for this. Just a tip though, you need to delete snapshots first, as otherwise disk sizes are locked from being changed.

    Reply
  2. *protectedwtcthomas says

    06/19/2015 at 2:19 am

    I wanted to change from tiny to small deployment, I follow the steps above but I got result = 1, disks have not changed using df -h
    thanks

    Reply
  3. *protectedtom says

    06/19/2015 at 2:29 am

    sorry, typo, it works. thanks

    Reply
  4. *protectedAlfonso says

    10/01/2015 at 6:32 am

    Thank you, William.

    That post saves me, and allows me to import current vcsa 5 database without problem.

    Reply
  5. *protectedChip says

    10/06/2015 at 8:58 pm

    William, I noticed this works on some of the vdisks but not all. For example, if you needed to extend Hard disk 1, vpxd_servicecfg storage lvm autogrow will not work. Since none of the vSphere 6 documentation I could find mentions this ability, what are some other caveats around using autogrow?

    Reply
    • *protectedRandomizer says

      08/19/2016 at 8:15 am

      I realize this is old, but for anyone else curious why autogrow doesn't work on disk 1 (also won't work on 4) it's because those two are partitions (/dev/sdx), not logical volumes. The caveat is that you can only use it on LVMs.

      To extend a partition you'd probably need to follow something along the lines of this KB: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2056764

      Reply
  6. *protectedJoe Cooper says

    11/30/2015 at 7:29 pm

    Any idea on how to do this on an external PSC appliance? vpxd_servicecfg doesn't appear to be on the server.

    Reply
    • *protectedJohn Maxwell says

      01/06/2016 at 11:36 am

      I have that question as well. My PSC /storage/log vol is full. its only 5GB and I would like to increase it

      Reply
      • *protectedAtleJensen says

        02/25/2016 at 6:31 am

        I would also like to know this.

        Reply
        • *protectedCedric C. says

          02/26/2016 at 9:18 am

          Same problem for Me !!

          Reply
          • William Lam says

            02/26/2016 at 9:53 am

            When a PSC is deployed externally, it looks like it does not include this new utility to easily increase volumes. This is something that VMware is aware of and will be fixing in the next update of vSphere.

            In the meantime, it sounds like this might be related to this KB (https://kb.vmware.com/kb/2143565) in which heavy logging from PSC is actually causing the log volume to fill up. If this is the case, simply increasing the capacity of the disk won't help as you'll probably run into this problem again

    • *protectedecmanfra says

      03/30/2016 at 8:48 am

      unfortunately this is still an issue, still can't expand any of the disks on a external psc =(

      Reply
      • William Lam says

        03/30/2016 at 10:55 am

        Joe,

        That's correct, the behavior hasn't changed even with the latest U2 release. I believe this will be fully resolved in a future update. In the meantime, curious if you're needing to expand the VMDK due to the PSC logging or for some other reason? We have a KB documenting on how to enable log rotation

        Reply
        • *protectedJoe Cooper says

          07/15/2016 at 7:15 am

          Yup... it's all about that log directory. I'll follow the KB and apply the workaround.

          Reply
  7. *protectedzachary says

    05/06/2016 at 10:08 pm

    can not increase the root partition on VCSA6.0 by using this way. any suggestion?

    Reply
    • *protectedGopi says

      05/08/2016 at 2:56 pm

      https://blog.pivotal.io/labs/labs/increasing-size-vcsa-root-filesystem

      Reply
  8. *protectedWes says

    10/02/2016 at 10:27 pm

    Longtime reader, huge fan, and this tip just saved from log disk headaches. Thanks William!

    Reply
  9. *protectedRyGuy says

    10/11/2016 at 10:49 am

    Any new updates for external PSC?

    Doing this workaround is Looney Tunes; https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2143565

    Reply
  10. *protectedKen says

    02/09/2018 at 6:17 am

    OK, so what if its not the DB volume that needs to be extended? In my case it was the log volume.. since it was just up one volume up from the DB I assumed it would be VMDK 5, and it was, but this was a guess based on an assumption that could have been faulty. More details on this would be appreciated.

    Reply
  11. *protectedcr0ft says

    04/03/2019 at 6:26 am

    The whole system eating logs thing is a pain in my arse. Yes, we're behind on upgrades, still using 6.0, but our system has fallen over several times due to this issue. First it was the well known screwup that there was no log rotation, so I fixed that. Then some other log filled up elsewhere and borked us, so I fixed that. Now, today, I think it was wrapper.log in /usr/lib or something that filled up the root partition and again I was doing the whole ssh in and hunt for the culprit. I'm moving to 6.5... and going over and increasing all those partitions that it makes to double the norm. Perhaps that won't break in the next couple of weeks. Meh...

    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

  • 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
  • vCenter Server Identity Federation with Kanidm 04/10/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...