{"id":14503,"date":"2026-10-21T21:37:29","date_gmt":"2026-10-21T19:37:29","guid":{"rendered":"https:\/\/irg-net.com\/?p=14503"},"modified":"2026-10-21T21:41:55","modified_gmt":"2026-10-21T19:41:55","slug":"removing-vcf-log-management-9-1-to-free-up-2-tb","status":"publish","type":"post","link":"https:\/\/irg-net.com\/index.php\/removing-vcf-log-management-9-1-to-free-up-2-tb\/","title":{"rendered":"Removing VCF Log Management 9.1 to Free Up 2 TB"},"content":{"rendered":"
\n
\"\"<\/figure>\n<\/div>\n\n\n
<\/div>\n\n\n\n

I run a 24\/7 Dell XR4000 Prod’ Cluster that does not have a lot of storage to spare. With VMware vSphere Foundation (VVF) 9.1, Log Management (formerly VCF Operations for Logs) became an integrated service that runs on the VCF Management Services platform, and in my environment it was taking up almost 2 TB. For a cluster of my size that is simply too much, and I do not need centralized log management there. So the decision was easy: Log Management has to go.<\/p>\n\n\n\n

What I expected to be a quick click in the UI turned into a small adventure. There is no uninstall button, I needed a cleanup script from Broadcom, the script needs the admin@vsp.local<\/strong> password, and I had no idea what that password was. This post walks through everything I did, including both password resets, so you do not have to piece it together from several knowledge base articles like I did.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n

Log Management 9.1 can be removed with Broadcom\u2019s cleanup_component.py script. The script logs in as admin@vsp.local. If you do not know that password, you can reset it on a control plane node of the VCF Services Runtime. For that you need SSH access as vmware-system-user, whose password can also be reset. The script runs from any machine with Python 3 \u2013 in VVF there is no SDDC Manager and you do not need one.<\/p>\n<\/blockquote>\n\n\n\n

<\/div>\n\n\n\n

The Environment<\/h3>\n\n\n\n
    \n
  • VMware vSphere Foundation (VVF) 9.1.1, managed through VCF Operations<\/li>\n\n\n\n
  • Log Management component version 9.1.1.0.25679624, deployed natively on VCF Management Services<\/li>\n\n\n\n
  • Fleet Lifecycle<\/li>\n\n\n\n
  • VCF Services Runtime <\/li>\n\n\n\n
  • An Ubuntu VM to run the script from<\/li>\n<\/ul>\n\n\n\n
    <\/div>\n\n\n\n

    Why there is no simple uninstall<\/h3>\n\n\n\n

    In VCF\/VVF 9.1 several components can be deployed after the initial setup under Build \u2192 Lifecycle \u2192 VCF Management \u2192 Components \u2192 Add Component<\/strong>. When I looked for the opposite function, there was none. At the time of writing, I could not find an uninstall workflow in that UI.<\/p>\n\n\n\n

    What Broadcom provides instead is a Python script, cleanup_component.py, attached to a knowledge base article (KB 441333). William Lam also describes it in a blog post about uninstalling optional Day-N components. A few things to know before you use it:<\/p>\n\n\n\n

      \n
    • The KB lists VCF 9.1 and VVF 9.1 as the environment. It does not apply to 9.0 deployments, where components are deleted directly in Fleet Management.<\/li>\n\n\n\n
    • For a natively deployed Log Management 9.1<\/strong> (running on VCF Management Services) the script removes the solution completely from the fleet. That was my case, and it uses the vsp-component commands.<\/li>\n\n\n\n
    • For a Log Management that was imported from 9.0<\/strong> (OVA appliance), the script only removes the entry from the fleet lifecycle. The old appliance keeps running and has to be deleted separately. That variant uses ova-component.<\/li>\n<\/ul>\n\n\n\n
      <\/div>\n\n\n\n
      \n

      Warning:<\/strong> Removing the component is irreversible. Broadcom\u2019s KB explicitly asks you to make sure you have a backup of any logs or data you still need before running the cleanup. If you change your mind later, you can deploy Log Management again via Add Component, but the old data will be gone.<\/p>\n<\/blockquote>\n\n\n\n

      <\/div>\n\n\n\n

      The Catch: two passwords I did not remember<\/h3>\n\n\n\n

      The script authenticates against the VCF Services Runtime as admin@vsp.local. Every VCF Services Runtime has two accounts:<\/p>\n\n\n\n

        \n
      • vmware-system-user<\/strong> is the local OS account that you use to SSH into a Services Runtime node.<\/li>\n\n\n\n
      • admin@vsp.local<\/strong> is the API account used to talk to the components running on the platform. This is the one the cleanup script needs.<\/li>\n<\/ul>\n\n\n\n

        Both passwords are set during the deployment of the VCF Management Services. The password you enter in the deployment wizard is used as the initial value for both accounts, and it is only visible in the Deployment UI. I did not have it anymore.<\/p>\n\n\n\n

        The two resets depend on each other like this:<\/p>\n\n\n\n

          \n
        • For the cleanup script I only need the admin@vsp.local<\/strong> password.<\/li>\n\n\n\n
        • To reset admin@vsp.local, I need a shell on a control plane node of the VCF Services Runtime, which means SSH access as vmware-system-user<\/strong>.<\/li>\n\n\n\n
        • So: if you do not know vmware-system-user either, do Option 1 first. If you do know it, skip straight to Option 2.<\/li>\n<\/ul>\n\n\n\n
          <\/div>\n\n\n\n

          Option 1: Resetting the vmware-system-user password<\/h3>\n\n\n\n

          This follows Broadcom KB 444453. The idea is to boot a control plane node into single-user mode, create a temporary user, and use it to write a new password into a Kubernetes secret. That secret then drives the password update on all VMs of the cluster.<\/p>\n\n\n\n

          <\/div>\n\n\n\n
          \n

          Heads-up:<\/strong> The change is cluster-wide. As soon as the Kubernetes secret is patched, all virtual machines in the cluster update the password for vmware-system-user. I also recommend taking a VM snapshot of the control plane node before you reboot it into single-user mode. That snapshot is my own precaution and is not part of the KB.<\/p>\n<\/blockquote>\n\n\n\n

          <\/div>\n\n\n\n

          Step 1: Find a control plane node<\/h4>\n\n\n\n

          In VCF Operations go to Build \u2192 Lifecycle \u2192 VCF Management \u2192 Components<\/strong>, open the VCF services runtime<\/strong>, scroll to the Nodes<\/strong> section and note the name and IP address of a Control Plane<\/strong> node. If the control plane node is not visible there, the KB suggests looking at the memory usage of the VMs in vCenter. The control plane node is the one with the lowest memory usage.<\/p>\n\n\n\n

          Step 2: Boot into single-user mode<\/h4>\n\n\n\n

          In the vSphere Client open a console for that VM and choose Power \u2192 Restart Guest OS<\/strong>. When the Photon bootloader screen appears, press e, move the cursor to the end of the kernel command line, add the following, and press F10:<\/p>\n\n\n\n

          <\/circle><\/circle><\/circle><\/g><\/svg><\/span>