I needed a VPS to run CyberPanel. Simple enough: 1 vCPU, 1 GB RAM, 10 GB SSD, IPv6 only. CyberPanel needs IPv4, so I upgraded to the next tier: 2 vCPU, 2 GB RAM, 20 GB SSD, one IPv4 address.
What followed was two separate infrastructure failures in the same 24 hours, from the same provider, on the same instance. Neither was a Linux problem. Both were provisioning problems — the gap between what an offer promises and what actually gets attached to the virtual machine.
I'm not naming the provider. It's a small French hosting company, and the point of this article isn't to send traffic their way — it's the pattern itself, which is common enough in the VPS world to be worth documenting properly.
Problem 1: IPv4 that went nowhere
The upgrade completed and the new IPv4 address showed up in the panel. Interface up, IP configured, default route present, ARP resolution to the gateway working:
88.151.197.1 lladdr 44:4c:a8:fb:ef:fd REACHABLE
But ICMP got no response at all, from the VPS or from the gateway itself:
88.151.197.112 > 88.151.197.1: ICMP echo request
(no reply)
IPv6 worked normally throughout. Everything on the guest side — interface, routing, ARP — was correct. That's a useful diagnostic signal in itself: when ARP resolves but ICMP is silent, the guest OS has done its job and the problem sits in the infrastructure layer above it — typically a MAC/IP binding on the hypervisor or virtual switch that hasn't been updated to match the new address.
It eventually got resolved, but with no explanation of what was actually changed on their side. At that point I'd lost most of a day to a connectivity problem on an instance that, on paper, was correctly configured from the first minute.
Problem 2: the disk that was never there
With IPv4 finally working, I moved on to installing CyberPanel — the entire reason for the upgrade. A fresh Ubuntu install went fine until CyberPanel's dependency installation started throwing No space left on device. So I checked:
root@panel:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 3.5G 0 disk
├─sda1 8:1 0 2.5G 0 part /
├─sda14 8:14 0 4M 0 part
├─sda15 8:15 0 106M 0 part /boot/efi
└─sda16 259:0 0 913M 0 part /boot
The disk was 3.5 GB. Root partition, 2.5 GB. The offer promised 20 GB after the upgrade — and, as it turned out, the base 10 GB tier had never delivered more than a fraction of that either. This wasn't a side effect of the upgrade. It had been wrong from the start; the upgrade just moved the goalpost from 10 GB to 20 GB while the actual allocation stayed untouched.
This is where a lot of guides point you at growpart or resize2fs. Both are useless here, and understanding why matters:
resize2fs and growpart operate at the bottom two layers. They can only extend a filesystem or partition into space that already exists on the virtual disk. If the disk itself is 3.5 GB, there is no unallocated space to grow into — the tools report success or do nothing, because there's genuinely nothing for them to do. The problem isn't in the guest OS. It's one layer below it, in what the hypervisor actually attached to the VM.
I opened a support ticket, included the lsblk output, and asked them to check the volume attachment.
The reply I got back attributed the disk shortfall to "the IPv6 to IPv4 upgrade" — as if provisioning a new IPv4 address could somehow shrink a virtual disk. It doesn't, and the two are unrelated at every layer shown in the diagram above. It reads less like a diagnosis and more like a convenient way to fold a second unresolved ticket into the first.
Problem 3: "fixed" didn't mean fixed
The provider's answer was to ask me to check again — no diagnosis of their own. I did, and this time the disk was correct: 20 GB, as ordered. I replied "corrected, thanks," and the ticket was closed.
Later the same day, I reinstalled Ubuntu to get a clean baseline. The disk was wrong again — same as before the fix, not as after it:
root@panel:~# date
Mon Aug 3 20:56:49 UTC 2026
root@panel:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 3.5G 0 disk
├─sda1 8:1 0 2.5G 0 part /
├─sda14 8:14 0 4M 0 part
├─sda15 8:15 0 106M 0 part /boot/efi
└─sda16 259:0 0 913M 0 part /boot
sr0 11:0 1 4M 0 rom
Same 3.5 GB disk, same 2.5 GB root partition, hours after the ticket was marked resolved.
This is the part worth sitting with. A "fix" applied through a support ticket, on a running instance, doesn't necessarily touch the thing that's actually broken. If the underlying VM profile or provisioning template is wrong, a support agent can patch the live disk allocation by hand and call it closed — while the next rebuild pulls from the same broken template and reproduces the exact same fault. The fix fixed an instance, not the cause.
That's the practical lesson: if a resource-provisioning issue gets "corrected" on a live VPS, don't close the loop until you've verified it survives a rebuild. A one-off patch and a fixed template look identical from the support ticket. They don't look identical from lsblk.
What two failures in one day tell you
Individually, either of these could be dismissed as a one-off glitch. Together, they're more telling: two independent provisioning mismatches — disk and network — on the same instance, within the same upgrade cycle, one of which reappeared after being marked fixed. That pattern points to the provisioning pipeline itself, not to isolated bad luck.
Commands worth knowing
If you land in a similar situation, these will tell you which layer you're actually dealing with:
lsblk # what Linux sees attached
fdisk -l # partition table detail
df -h # filesystem usage
blockdev --getsize64 /dev/sda # raw device size, bytes
ip addr # interface and IP state
ip route # routing table
ip neigh # ARP/NDP cache — gateway reachability
ping -c 3 <gateway> # basic reachability test
If lsblk and blockdev --getsize64 already show a disk smaller than what you're paying for, don't touch growpart or resize2fs — you're not looking at a Linux problem. If ip neigh shows the gateway as REACHABLE but ping gets nothing back, you're not looking at a Linux problem either. In both cases, the fix is on the other side of the hypervisor boundary, and no amount of guest-side troubleshooting will reach it.
Takeaway
A VPS isn't physical hardware, but it's supposed to honor the same basic contract: the resources advertised should be the resources actually present. Before blaming Linux, a package, or your own configuration, check the layer underneath — and if a provider tells you something's fixed, verify it survives a rebuild before you believe it.
None of this required an unusual amount of digging — lsblk, ip neigh, a rebuild to double-check. Which is really the point: for roughly the same price, sometimes less, providers like OVH, Contabo, or Infomaniak offer configurations that don't require this kind of forensic work just to get the resources you paid for. Chasing the cheapest listed price has a cost. It's just not always visible until you've already lost a day to it.
Top comments (27)
Great job! And yes, resource allocation on servers is a dodgy one, that's how Google offers you terabytes worth of storage included in any subscription, because they know nobody would use even a fraction of it. Essentially that 2tb, or whatever is 'allocated' actually isnt, it's just a promise and they know they cant deliver if everyone actually used it. If everyone filled up their Google Drives, Google would error out before even 1/3rd finished. Because they know 99% of people use less than 100GB, the rest max use around 500GB. Result is over promise and deliver exactly what you use, because the probability of everyone needing it all at once, is impossible. Same goes for networking, IPv4 is a limited resource, so they have to shuffle it around in order to meet demands, but that also means you never get a fixed address online, you're likely sharing it with atleast 100 other instances. Serious security vulnerability if someone figures out how to exploit it properly, but that's just the nature of limitations.
Thanks! I completely agree that oversubscription is part of how many cloud services work. Storage, CPU, bandwidth... they're all based on statistical usage patterns rather than everyone consuming their full allocation at the same time.
What surprised me in this case was that it went beyond normal oversubscription. The VPS couldn't even sustain the resources it was explicitly sold with, under a perfectly ordinary workload. It wasn't a peak usage problem or a temporary contention issue—the capacity simply wasn't there from day one.
I don't mind shared infrastructure when it's honestly represented. What bothered me was paying for guaranteed specifications that the platform could never actually deliver.
Agreed, you are supposed to get what you pay for, especially if you pay a premium for exact specs and you didnt even ask for much, a few gb of ssd and an IP, those are literally the bare minimum for cloud
Exactly. What frustrated me most wasn't the lack of performance—it was the time lost debugging software that turned out to be innocent. Once you assume the advertised infrastructure is trustworthy, you naturally look elsewhere for the problem. In this case, the infrastructure itself was the root cause.
That's a lesson I'll definitely keep in mind for future investigations.
Actually points to a comment I left earlier today on another post, regarding abstraction layers. We treat high level languages as the norm, even though it's multi-layer abstractions of OpCodes and we just trust that Console.WriteLine() works, we dont question if it has a bug, we just assume and that assumption is exactly what caught you here, you assumed that paying for infrastructure meant your infrastructure 'just works' and that's the same assumption I make when I used a SnackBar in Blazor and my 1 UI button on a dialog didnt work... I assumed Blazor just works, I never considered till after hours of debugging that it was actually the SnackBar not disposing properly that was causing the issue.
That's a very good analogy. The higher the abstraction level, the more we rely on assumptions because we simply cannot validate every layer every time.
A developer debugging an application usually starts at the application layer, not by checking if the CPU instructions generated by the compiler are correct. Likewise, when renting a VPS, you normally start by looking at your configuration, your services, your code—not by questioning whether the provider actually delivered the resources advertised.
The tricky part is that sometimes the layer we consider "trusted" is exactly where the problem is. Good debugging is often about knowing when to break the abstraction and verify the foundations again.
Your Blazor example is a perfect illustration of that: the framework was not the problem, but the assumption that "this component behaves as expected" delayed finding the real cause.
Exactly, just how your IDE throws errors, when it was actually the IDE reading stale DLLs, you first think it's missing dependencies, without considering it was a partial build that broke it.
Exactly. The visible symptom is often just the last place where the problem surfaces, not where it actually started.
That's why debugging can be so deceptive: the IDE reports a compilation issue, the application reports an error, the server reports a timeout... but the root cause may be somewhere else entirely.
The hardest part is not always finding the fix—it's identifying which assumption to challenge first. In my VPS case, the assumption was "the infrastructure matches the specifications". Once that assumption was questioned, the rest of the investigation became much simpler.
And the real time consumer is that errors just bubble up, they dont drill down. In your case software failed to write, but it had no idea that your drive is meant to be 20gb, so it just assumed you're full, instead of being capable of saying 'hey your VPS isnt matching the spec advertised', kinda funny, because if you set it all up with AI and it was the manager for it, it would have picked up on that instantly, but for us, that takes a while to get to
Exactly, and that's probably one of the biggest challenges in modern systems: errors usually describe the failure at the layer where they happen, not the reason why they happened.
The application only knows: "I tried to write data and the filesystem returned no space left". It doesn't know: "this VPS was advertised with 20GB but the underlying storage doesn't match that expectation".
What makes debugging difficult is that humans usually investigate from the inside out: application → configuration → OS → hardware → provider. Sometimes the answer is in the opposite direction: verify the foundations first.
An AI agent with access to infrastructure metrics, provisioning data and expected specifications could probably correlate those signals much faster. But the important part is not AI itself—the important part is having enough visibility across the layers.
That's why if it had the equivalent to a task manager, it would have probably made life alot easier
Yes, exactly. A traditional task manager only shows the current state of a machine: processes, memory, CPU usage, disk activity. What would really help is something closer to a "system context manager" — something that also knows the expected state.
Not only "the disk is full", but "this machine was supposed to have 20GB available, the filesystem reports 5GB, and the storage layer shows unexpected allocation".
The difficult part is not collecting metrics anymore; we have plenty of monitoring tools. The difficult part is connecting the dots between the observed state and the intended state.
That's probably where AI agents could become genuinely useful in operations: not replacing troubleshooting, but reducing the time spent finding which assumption is wrong.
That's where the cloud providers like Azure and GCP are getting there, the 'ask copilot' or 'ask gemini', which permissions restricted, still give you better insight than you can practically search for, unless you know the platform inside out. Eg. In Azure, to try and find your monthly usage... Why they cant just put a Usage page with sub-tabs for what you use, is beyond me, but I guess that's cloud orchestrators' headache, not mine. Yeah the Task Manager, while useful in windows, could do with an upgrade. Eg. Why can it show my GPU's temp, but not CPU, despite HWMonitor being able to do just that? Makes no sense to me and why Cloud orchestrators dont have a similar window for just viewing the overall stats
I think that's exactly the point: we don't really lack data, we lack a good way to navigate and interpret it.
Cloud platforms have thousands of metrics, logs, dashboards and configuration options, but the challenge is knowing where to look and understanding the relationships between them. A human expert builds that mental map over years; an AI assistant can potentially act as a bridge between the raw complexity of the platform and the question you actually have.
The interesting evolution would not be just "show more metrics", but "explain what matters". For example: "Your application is failing because the disk is full" is useful, but "your disk is full because the allocated storage does not match the expected specification from your plan" is the kind of cross-layer explanation that saves hours.
Maybe the future Task Manager is less a dashboard and more a diagnostic assistant.
Sounds good, not too unrealistic either, think about the VPS for instance, you have a promise and a state, if the state doesnt match the promise, there's a problem. Like a GPU that reports 8GB, but is from Temu, so it actually just has 1.5GB, if the state doesnt match the promise, it's flagged, so your dashboard is rather a list of flags and possible causes, with quick resolution shortcuts, instead of just metrics
I really like that way of framing it. The comparison shouldn't be current state vs. current state, but current state vs. expected state.
Monitoring today is mostly descriptive: "CPU is 85%", "disk is full", "memory is low". What's missing is the semantic layer that says: "this system is not behaving as promised."
Your VPS example is exactly that. The expected state was "20 GB SSD". The observed state was something that behaved as if that capacity wasn't actually available. The interesting event wasn't "disk full"—it was "contract violated".
I could imagine a future operations dashboard showing exceptions to expectations instead of raw metrics. Humans are much better at investigating why this expectation failed than at scanning hundreds of graphs looking for anomalies.
Great article, Pascal! 🙂 I really like how it illustrates the right way to approach debugging: understanding the root cause first instead of blindly throwing hotfixes at the problem, which unfortunately happens far too often. 😄
Thanks, Sylwia! 🙂 I completely agree. I've found that many "technical" problems are actually symptoms rather than causes. If you only fix the symptom, you often end up building workarounds on top of a faulty foundation. This case was a good reminder that before questioning the software, it's worth questioning the assumptions—even the infrastructure itself. 😄
Great article and insights.
Thanks, Ken! Much appreciated. 🙂
The rebuild test is the key takeaway here. A VPS can look “fixed” at the guest level while the underlying provisioning template is still broken. Always verify the resources after a rebuild.
Exactly. A rebuild is a much better test than simply resizing the filesystem. If the VM comes back with the same undersized virtual disk, the problem is clearly above the guest OS. That's why verifying the actual resources after a rebuild should be part of the troubleshooting process.
Exactly. Verification is just as important as the rebuild itself. The same principle applies to trading infrastructure — you need reliable data, transparent tools, and proper risk management to make better decisions.
That’s one of the ideas behind Tyrian Trade — bringing market data, trading tools, strategy research, and a trusted trading community into one platform. Worth checking out if you're interested in building a more systematic trading workflow.
The point about support patching the live instance vs actually updating the VM template is so spot on. I’ve burned hours on this exact thing before—support runs a quick command on the host, marks the ticket resolved, and the second you rebuild or redeploy, you’re right back at square one because the base template was broken all along. Testing a rebuild before closing the ticket is a rule I'm definitely stealing.
Exactly. That distinction is what I found most interesting in this case: fixing the live VM can make the problem disappear temporarily, while a rebuild exposes whether the underlying provisioning is actually correct.
I think “test the rebuild before closing the ticket” is a pretty good rule for VPS support in general.
This is such a frustrating kind of problem because everything looks fine on paper. Sometimes the real headache isn’t Linux at all, but what the provider actually gives you.
Exactly. Or rather, sometimes the real headache is what the provider doesn't give you — despite what you actually paid for.