Running a homelab with Proxmox

Many people start their homelab journey with a simple impetus. A question on "I wish I had this at home", or "I want to do more with this". For me, that question came to me from my kids. They asked if they could have a server running the rather popular game Minecraft. I had long been interested in the space, but hadn't had any spare hardware. The most I had was a used HP Compaq 6200 Pro SFF PC that I had scrounged out of my work's recycling pile. It was sporting a blazing fast Intel Core i5-2400 Quad Core 3.1GHz processor and 4GB RAM.

As a software developer, I had some experience with running virtual machines on my own computer, and had just been getting into adding Docker to my toolbelt. When I had decided to bend to the wishes of my children and provide them with a Minecraft server, I obviously checked if there was a docker container for it. At the time, although I could use Docker directly, I was more comfortable with using Compose. This worked, but requires one to provision, and more importantly remember, a different port for every service. This is fine in general for a few services, but as I was adding more things, including my own projects, I was finding it more and more difficult to remember where to go to find things, even with a carefully curated list.

After struggling with this for longer than I perhaps should have ("I'll look into it tomorrow.", "It's annoying, but it's working."), I decided to look for a proper solution using virtual machines. This would allow me to ubiquitously use port 80 (or whatever port the service was developed to use), and I would then just have to remember more friendly hostnames, with a small configuration change.

The solution I settled on briefly was a Type 2 hypervisor, Oracle VirtualBox, as this is easily cross platform and was what I was most comfortable using, but made connecting from outside hosts a little tricky without extra configuration. After banging my head against the wall for more time than I would care to admit, I found out about KVM and virt-manager.

Although this allowed me to more easily connect to my virtual machine run services from external hosts, it still required my system to either be tethered with a mouse, keyboard and display or forwarding X11 during ssh. As I have very limited desk space in my workspace, adding another mouse, keyboard and monitor was untenable in the long run and X11 and ssh were adding ridiculous amounts of lag over my aging 10/100Mb switches.

I was talking it over with my co-worker and he had suggested I look into Windows Server and Hyper-V. This became a fantastically in depth conversation about running virtual machines in a home or small business setting as well as the different types of Hypervisors.

Hypervisors

Hypervisors are split into two types, Type 1 and Type 2 that determine what you can do with them. Type 2 hypervisors are virtual machine managers that run inside a host such as Windows or macOS, like VirtualBox above. They are generally easy to install, and work well for managing virtual machines on a single device. They don't, however, allow for much beyond that. That's where Type 1 Hypervisors come into play. Type 1 Hypervisors are usually operating systems in themselves and usually have minimal if any user interface on a plugged in display. They are made to be managed remotely (or at least from another machine on the network), usually through a web interface.

I've gone and made a list of the ones I've heard the most of below as well as some features they promote. This is by no means exhaustive and I encourage anyone exploring the space to do their own research:

• VMware VSphere

  VMware VSphere has two main editions: Standard and Enterprise Plus. The reasons VMware lists to use VSphere include:

  • Provide business continuity and always-available IT.
  • Improve Service levels and application quality.
  • Reduce IT footprint and simplify management.
  • Save on IT hardware costs.
  • Strengthen security and data protection.

  The cost for VMware VSphere Standard is currently $1268.00USD.

• Citrix Hypervisor

  Citrix Hypervisor is a spin off of their XenServer project. Citrix provides the following reasons to use it:

  • A smarter way to speed, support, and secure virtual environments.
  • Empower users with enhanced graphics workloads.
  • Simplify endpoint management.
  • Help focus your security.
  • Migrate to a work from everywhere environment.

• Microsoft Azure Virtual Machines

  Microsoft's offering is a cloud based solution. Microsoft gives to following reasons to use Azure Virtual Machines:

  • Keep your budget in check with low-cost, per-second billing. You only pay for the compute time you use.
  • Scale from one to thousands of VM instances in minutes with Azure Virtual Machine Scale Sets.
  • Encrypt sensitive data, protect VMs from malicious threats, secure network traffic, and meet regulatory and compliance requirements.
  • Choose Linux or WIndows. Deploy your own VM image or download images from teh Azure Marketplace.

• Proxmox VE

  In contrast to the above, Proxmox VE is a free, open source, Enterprise grade virtualization engine. Proxmox provides:

  • Use either full virtual machines through KVM or lighterweight Linux Containers.
  • Provide high availability virtual machines by deploying in a cluster.
  • Enable scheduled full VM backups.
  • Out of the box firewall rules for all hosts or specific VMs/containers.

After more research, I settled on using Proxmox. It was free and open source, which is very important to me, is based on Debian, and can be put on most systems developed in the last 2 decades with some limitations.

Proxmox Requirements

As per the Proxmox Docs, the recommended hardware for running a Proxmox node are currently as follows: - Intel EMT64 or AMD64 with Intel VT/AMD-V CPU flag. - Memory, minimum 2 GB for OS and Proxmox VE services. Plus designated memory for guests. For Ceph or ZFS additional memory is required, approximately 1 GB memory for every TB used storage. - Fast and redundant storage, best results with SSD disks. - OS storage: Hardware RAID with batteries protected write cache ("BBU") or non-RAID with ZFS and SSD cache. - VM storage: For local storage use a hardware RAID with battery backed write cache (BBU) or non-RAID for ZFS. Neither ZFS nor Ceph are compatible with a hardware RAID controller. Shared and distributed storage is also possible. - Redundant Gbit NICs, additional NICs depending on the preferred storage technology and cluster setup - 10 Gbit and higher is also supported. - For PCI(e) passthrough a CPU with VT-d/AMD-d CPU flag is needed.

Additionally, in order to use the web interface for management you will need:

• Mozilla Firefox, a release from the current year or the latest Extended Support Release.
• Google Chrome, a release from the current year.
• Microsoft's currently supported version of Edge.
• Safari, a release from the current year.

Installing Proxmox

Installing Proxmox is about as easy as installing most other operating systems, but does require access to the internet and a spare USB flash drive. To begin, download the current latest ISO installer.

Once that's been successfully done, you will need to write it to the USB flash drive. On Windows, you can use a program like Rufus. In Rufus, select the ISO you just downloaded, select the USB flash drive, and click START. On Linux or macOS, my current preferred bootable USB creation tool is Balena Etcher. Similarly, run the program, select the image, select the drive and click "Flash!". Etcher is available for Windows, but I have had issues with it in the past. Rufus has been more consistent for me. On Linux, you may need to run Etcher with root privileges, but it should prompt for your password if needed. Once done, eject the stick from your computer, insert it into the computer to install Proxmox on and boot to it. Although the installer does include a full GUI, you can perform the install using only a keyboard. To press buttons, you can press ALT and then the underlined letter. ALT+N for instance presses the next button.

After the system has restarted, further configuration is to be done through web interface. This is located at https://<chosen-ip-address>:8006. The default user name is root and the password is defined during the installation.