Successfully Installed Harvester on Surface Pro 5, But Unable to Create VMs Due to CPU Resource Shortage
Previously, I accidentally damaged the LCD display of my Surface Pro 5 (Model 1796) during a battery replacement repair. Up until now, it has lived out its remaining days as a headless Minecraft server. However, wanting to utilize the resources of its Intel Core i7-7660U (2 cores, 4 threads) more efficiently and modernly, I decided to try installing “Harvester," an open-source hyperconverged infrastructure. I attempted to transform it from a single-OS environment running a single service into a “private cloud" capable of spinning up VMs (virtual machines) on demand.
What Exactly is “Harvester"?
Let me briefly explain Harvester, which I introduced this time.
Harvester is an open-source HCI (Hyperconverged Infrastructure) primarily developed by SUSE, a long-standing Linux distribution vendor.
When you hear “HCI," it sounds complicated, but roughly speaking, it’s “a magic OS that lets you build your own Amazon AWS-like environment just by installing it."
- Hypervisor (Virtualization): KubeVirt (technology for running VMs on Kubernetes)
- Storage: Longhorn (technology for pooling multiple disks)
- Networking: Multus (advanced network control)
All of these come bundled right out of the box and are installed directly onto bare metal (the PC itself). Because the internals are entirely built on Kubernetes, it is easy to manage for anyone with k8s knowledge, and its UI is exceptionally refined.
OS Installation was Surprisingly Smooth
I had the preconception that “since it’s a dedicated OS, installation must be difficult," but the actual procedure was very simple.
- Download the ISO image from the official website.
- Write it to a USB flash drive from WSL using the dd command.
- Boot the Surface from the USB and follow the CLI instructions to configure settings.
The installation completed surprisingly smoothly, and the OS setup ended up being anti-climactically straightforward. However, the real battle awaited after the reboot.
Pods That Won’t Start and the “503" Wall
After rebooting, hitting the management interface (HTTPS) from a browser returned nothing but the text “503 Service Unavailable."
Checking the internals from the console with kubectl get pods -A, I found that the Pods responsible for the Harvester dashboard were failing to start indefinitely. Looking at the details via kubectl describe, the cause was crystal clear: “Insufficient cpu."
To stabilize the system, Harvester components attempt to “reserve" a certain amount of CPU resources. Within the limited framework of 4 threads (equivalent to 4000m), the infrastructure-side Pods alone consumed the entire reservation quota, leaving not a single “chair" left for the management dashboard Pod.
“Surgery" to Erase the Reservation Quota
Since I couldn’t even log in like this, I tried a brute-force method of ignoring Kubernetes rules.
I ran kubectl edit deployment harvester -n harvester-system and boldly rewrote the reservation settings (Requests) in the resources section to resources: {}.
By emptying out the command that dictates “ensure at least this much CPU," the scheduler reluctantly started the Pods. After waiting a few minutes, the Pods finally reached the Running state, allowing me to open the Harvester dashboard from my browser.
Conclusion: I Could See the Dashboard, but Had Zero Capacity to Create VMs
I somehow managed to log in, but the resource status displayed on the dashboard was unbelievable.
- CPU Reserved: 2.99 / 3.04 (98.19%)
- CPU Used: 3.99 / 3.04 (131.38%)
It was in an overflow state where just running the management infrastructure maxed out 130% of the physical processing capacity. Although it settled down to around 1.42/3.04 after leaving it idle for a while, if I tried to create a VM on top of this, it would obviously be rejected due to insufficient resources, or forcing it would crash the entire system.
The attempt to “put Harvester on a Surface Pro 5 and build a modern VM environment!" ended with a painful realization of the spec wall: “Installation and login were possible, but completely inadequate for practical use." As expected, there are good reasons behind the recommended specifications (8 cores or more).
Nando Kobo’s Summary
This Harvester deployment, undertaken with a “let’s just try it out" mindset, was easy when it came to the installation itself using a single dd command, but the subsequent resource tug-of-war was the toughest hurdle. Running an HCI on a 2-core, 4-thread mobile CPU was indeed a bit too reckless.
That being said, breathing the latest HCI into a broken Surface and getting to gaze upon that sleek dashboard fully satisfied my engineering curiosity.