Connecting a large language model to a live server without a control plane is a terrible idea. But when you put a governed system between an AI agent and your infrastructure, you can safely expand a Linux root filesystem from 38 GB to 115 GB without ever opening an SSH session. Tonight, I expanded the virtual disk on an Ubuntu GitHub runner VM in Hyper-V, asked ChatGPT to handle the host side, and let FlowRMM manage the execution.
The operational problem
I know how to make a virtual disk bigger in Hyper-V. What I do not know is the exact Linux storage sequence that comes after that.
I did not want to Google the logical volume management commands. I did not want to copy a shell script from an old forum post and hope it matched my specific partition layout.
If you already manage Linux every day, expanding an LVM-backed filesystem is standard work. You run growpart on the block device, resize the physical volume, and extend the logical volume. But knowing those commands is only one piece of the job.
Before running them, you need to know what disk you are touching, which partition contains the physical volume, which logical volume backs the root directory, and whether the filesystem can be expanded online. Running the right command against the wrong device is still the wrong outcome.
How FlowRMM controlled the workflow
FlowRMM gave ChatGPT access to the endpoint as an operator, not as an unrestricted shell, using the Model Context Protocol. First, it found the correct machine and confirmed it was an Ubuntu 24.04 virtual machine running in Hyper-V.
Then it inspected the current filesystem state. The root volume was about 38 GB, with 27 GB already used, sitting around 75 percent full.
The next check mapped the exact storage layout. It confirmed the LVM physical volume location, the logical volume backing the root filesystem, and that the root filesystem was ext4. It also verified that the growpart utility was available on the machine.
Only after that context was established did the system prepare the expansion command. And it did not just run it.
The approval boundary and measurable result
FlowRMM classified the storage change as a mutation that required human approval. I approved it in the FlowRMM action queue. Then the command executed against the exact endpoint we had inspected.
The logs showed the partition growing, the LVM physical volume resizing, the logical volume increasing to roughly 117 GB, and ext4 resizing online.
Finally, ChatGPT asked FlowRMM to verify the result. The final filesystem reported roughly 115 GB total, 27 GB used, 84 GB available, and only 25 percent utilization. Problem solved.
Why AI needs a control plane
The impressive part is not that an AI model can remember Linux syntax. The impressive part is the working system around the model.
The model had context about the actual endpoint. It could inspect state. It had a defined scope. Read-only operations could happen safely. A mutation crossed a strict approval boundary. The action executed through a managed agent, and the result was checked against the real machine.
That creates a reliable process that looks like this: Intent, inspect, understand, propose, approve, execute, verify.
For us, the answer is not to give an AI unlimited terminal access. It is to put a control plane between the intelligence and the endpoint, with visibility, permission, approval, execution, and a clear record of what happened.
Frequently Asked Questions
Does FlowRMM give AI models root access to endpoints?
No. FlowRMM acts as a strict control plane. Read-only inspection operations can happen safely, but any system mutation requires explicit human approval before execution.
How does the AI understand the real machine state?
FlowRMM uses the Model Context Protocol to expose specific, governed inspection tools. This allows the model to look at disk layouts, filesystem usage, and operating system details without having an open shell.
Why not just write an automation script?
Scripts are brittle when environments vary. This system translates a plain English intent into dynamic technical work, maps it to the specific state of the target machine, and stops at the point where human authorization matters.
The next step for operating computers
I did not know the exact process for expanding an LVM-backed Linux root disk when I started this task. I knew the operational goal. I expanded the virtual disk in Hyper-V, told ChatGPT what I wanted, and FlowRMM handled the machinery required to get there safely.
A business owner should not need to memorize registry paths, package managers, or LVM layouts just to operate the computers their business depends on. Technical knowledge still matters. Human judgment and approval still matter. But the person with the problem should be able to describe it and let a governed system assemble the tools needed to solve it.
We build the applications your business runs on. If you need working systems that connect software, data, and safe AI workflows, book a time with us at https://bookings.flowdevs.io.
Connecting a large language model to a live server without a control plane is a terrible idea. But when you put a governed system between an AI agent and your infrastructure, you can safely expand a Linux root filesystem from 38 GB to 115 GB without ever opening an SSH session. Tonight, I expanded the virtual disk on an Ubuntu GitHub runner VM in Hyper-V, asked ChatGPT to handle the host side, and let FlowRMM manage the execution.
The operational problem
I know how to make a virtual disk bigger in Hyper-V. What I do not know is the exact Linux storage sequence that comes after that.
I did not want to Google the logical volume management commands. I did not want to copy a shell script from an old forum post and hope it matched my specific partition layout.
If you already manage Linux every day, expanding an LVM-backed filesystem is standard work. You run growpart on the block device, resize the physical volume, and extend the logical volume. But knowing those commands is only one piece of the job.
Before running them, you need to know what disk you are touching, which partition contains the physical volume, which logical volume backs the root directory, and whether the filesystem can be expanded online. Running the right command against the wrong device is still the wrong outcome.
How FlowRMM controlled the workflow
FlowRMM gave ChatGPT access to the endpoint as an operator, not as an unrestricted shell, using the Model Context Protocol. First, it found the correct machine and confirmed it was an Ubuntu 24.04 virtual machine running in Hyper-V.
Then it inspected the current filesystem state. The root volume was about 38 GB, with 27 GB already used, sitting around 75 percent full.
The next check mapped the exact storage layout. It confirmed the LVM physical volume location, the logical volume backing the root filesystem, and that the root filesystem was ext4. It also verified that the growpart utility was available on the machine.
Only after that context was established did the system prepare the expansion command. And it did not just run it.
The approval boundary and measurable result
FlowRMM classified the storage change as a mutation that required human approval. I approved it in the FlowRMM action queue. Then the command executed against the exact endpoint we had inspected.
The logs showed the partition growing, the LVM physical volume resizing, the logical volume increasing to roughly 117 GB, and ext4 resizing online.
Finally, ChatGPT asked FlowRMM to verify the result. The final filesystem reported roughly 115 GB total, 27 GB used, 84 GB available, and only 25 percent utilization. Problem solved.
Why AI needs a control plane
The impressive part is not that an AI model can remember Linux syntax. The impressive part is the working system around the model.
The model had context about the actual endpoint. It could inspect state. It had a defined scope. Read-only operations could happen safely. A mutation crossed a strict approval boundary. The action executed through a managed agent, and the result was checked against the real machine.
That creates a reliable process that looks like this: Intent, inspect, understand, propose, approve, execute, verify.
For us, the answer is not to give an AI unlimited terminal access. It is to put a control plane between the intelligence and the endpoint, with visibility, permission, approval, execution, and a clear record of what happened.
Frequently Asked Questions
Does FlowRMM give AI models root access to endpoints?
No. FlowRMM acts as a strict control plane. Read-only inspection operations can happen safely, but any system mutation requires explicit human approval before execution.
How does the AI understand the real machine state?
FlowRMM uses the Model Context Protocol to expose specific, governed inspection tools. This allows the model to look at disk layouts, filesystem usage, and operating system details without having an open shell.
Why not just write an automation script?
Scripts are brittle when environments vary. This system translates a plain English intent into dynamic technical work, maps it to the specific state of the target machine, and stops at the point where human authorization matters.
The next step for operating computers
I did not know the exact process for expanding an LVM-backed Linux root disk when I started this task. I knew the operational goal. I expanded the virtual disk in Hyper-V, told ChatGPT what I wanted, and FlowRMM handled the machinery required to get there safely.
A business owner should not need to memorize registry paths, package managers, or LVM layouts just to operate the computers their business depends on. Technical knowledge still matters. Human judgment and approval still matter. But the person with the problem should be able to describe it and let a governed system assemble the tools needed to solve it.
We build the applications your business runs on. If you need working systems that connect software, data, and safe AI workflows, book a time with us at https://bookings.flowdevs.io.
