Installing Proxmox on a Lenovo M710q: From an Empty Disk to the First VM

In the previous post, I explained why I chose a used Lenovo ThinkCentre M710q for my homelab. The hardware itself was only the beginning. To become useful, it needed a layer where I could safely run additional services.

Installing Proxmox did not take particularly long, but the decisions and one issue I encountered mattered more than clicking through the installer.

This post covers the path from an empty disk to the first Ubuntu Server VM. It is the third step in the series: after deciding to build a homelab and choosing the hardware, it was time to create the foundation for the actual development environment.

Why did I need a hypervisor in the first place?

My goal was not to learn Proxmox just for the sake of learning Proxmox. I wanted to build a development environment that runs independently of my laptop and is available whenever I need it.

Codex CLI, GitHub repositories, MCP integrations, and a future NAS were all meant to run on one small machine, but without mixing every responsibility into a single operating system.

Proxmox was not the goal by itself. It was a way to build a foundation for the next parts of the homelab: development, backups, monitoring, and experiments that I can grow step by step.

Why not install Ubuntu directly on the hardware?

The simplest option looked reasonable: install Ubuntu Server on the Lenovo and run everything there. That would be enough for one service. The problem starts when one machine takes on several roles.

I did not want an update to the development environment to affect a future NAS or monitoring service. I also did not want to rebuild the entire configuration after a failed experiment.

A hypervisor gives me a simple separation of responsibilities. Each machine can have its own resources, lifecycle, and backup. Taking a snapshot before a risky change costs less time than repairing the system afterward.

The plan before installation

Before starting the installer, I defined a simple target state:

• Proxmox VE runs directly on the Lenovo M710q,
• the administration panel is available only on the private network,
• the first virtual machine runs Ubuntu Server,
• the VM has a stable, predictable place on the network and is reachable over SSH,
• repositories, Codex CLI, and MCP integrations live inside the VM, not on the Proxmox host.

The last decision is important. The host should remain as simple as possible. Proxmox manages machines; it is not a place for daily development work.

Preparing the Lenovo M710q

Before installation, I connected the Lenovo to the router with Ethernet and attached a keyboard and monitor. Wi-Fi is convenient for a laptop, but a virtualization host should have a stable and predictable network connection.

In the BIOS, I checked the boot order and virtualization support. The second item became important later: the CPU supports VT-x, but a used computer does not necessarily have it enabled.

I prepared the installation USB drive from the official Proxmox VE ISO. Because the installation would use the entire disk, I first confirmed that it contained no data I needed.

Installing Proxmox VE

The installer requires a few concrete decisions: selecting the disk, regional settings, an administrator password, and network configuration. I paid the most attention to the network.

Proxmox needs an address where its administration panel remains available after a restart. I configured an address on my private home network, along with the correct gateway and DNS server. I then reserved the address on the router to prevent a future conflict.

After installation, I removed the USB drive and restarted the computer. The Proxmox panel was available from a browser on another device in the same network. I did not expose it to the public internet, and I still have no reason to do so.

The first mistake: no KVM hardware acceleration

The first attempt to create a virtual machine quickly revealed a problem:

No support for hardware accelerated KVM virtualization detected

The message suggested that the host could not use hardware virtualization. At first, it looked like a limitation of the Lenovo or its CPU, but the i5-7400T specification said otherwise.

The cause was simpler: Intel Virtualization Technology was disabled in the BIOS. After enabling it and restarting the host, KVM worked correctly.

This was the most practical lesson from the installation: with used hardware, do not assume the BIOS settings reflect the device's capabilities. Check them before diagnosing the operating system.

Networking: a bridge instead of manual workarounds

During installation, Proxmox creates a network bridge, usually named vmbr0. For virtual machines, it acts like a virtual switch connected to the Lenovo's physical interface.

This allowed the first VM to receive its own address on the same private network as the other devices. I did not need additional NAT or unusual routing rules. From the router's perspective, Ubuntu Server is a separate machine.

At this stage, simplicity mattered more than advanced segmentation. Separate VLANs and stricter rules will make sense later, when the homelab contains more services with different trust levels.

The first machine: dev-ubuntu

I named the first machine dev-ubuntu. Its purpose is clear: it is my private, always-available work environment.

Initially, I assigned it only part of the Lenovo's resources. There is no reason to give one VM all CPU, RAM, and disk space before collecting real measurements. Resources can be increased later in Proxmox, while free memory leaves room for more services.

During the Ubuntu Server installation, I enabled SSH. After the first boot, I updated the system, configured key-based login, and confirmed that I could connect from my main computer.

What went into the VM, and what stayed on the host?

The separation is intentionally simple:

Lenovo ThinkCentre M710q
│
└── Proxmox VE
    │
    └── VM: dev-ubuntu
        │
        ├── Workspace
        │   └── GitHub repositories
        │
        ├── Codex CLI
        │
        └── MCP Integrations
            ├── GitHub MCP
            └── Linear MCP

The Proxmox host handles virtualization, VM networking, and machine lifecycle. Developer tools run inside dev-ubuntu. If I break the environment configuration, I do not affect the foundation of the entire homelab.

Backup before optimization

After configuring the clean VM, I created the first backup. This is a useful moment because the system is already reachable over SSH but does not yet contain many dependencies and manual changes.

A snapshot is convenient before a short experiment, but it does not replace a backup stored independently from the running machine. Eventually, copies will move to separate storage; at this stage, the important part was building a recovery habit before the environment became important.

What did this installation teach me?

Installing Proxmox itself did not take the most time. Making a few simple decisions in the right order did.

• Define the roles of the host and VMs first instead of installing everything in one system.
• Predictable networking and SSH access matter more than an elaborate administration panel.
• With used office hardware, check the BIOS immediately, especially virtualization settings.
• A hypervisor host should remain boring and stable. Experiments belong inside VMs.
• Prepare backups before the moment when you truly need them.

What is next?

At this point, I had a working foundation: Proxmox on the Lenovo M710q and the first Ubuntu machine available over SSH. Only then did the homelab start serving its actual purpose.

In the next step, I will cover the development environment inside dev-ubuntu: GitHub repositories, Codex CLI, MCP integrations, and secure remote access. Proxmox will stay in the background, exactly where it belongs.