That was the idea.

Somewhere I could open Proxmox, UniFi and whatever else I eventually deployed without having to remember a collection of IP addresses and port numbers.

Nothing particularly elaborate.

By the end of 7 June 2026, I had another Ubuntu virtual machine, Docker Engine, Portainer, Homepage, Uptime Kuma, Vaultwarden and Nginx Proxy Manager.

I also had a few problems that hadn't been resolved.

It was becoming apparent that installing services was going to be considerably easier than organizing them properly.

Another VM seemed reasonable

I'd only just finished establishing the first two virtual machines on my newly installed Proxmox server.

ubuntu-mgmt-01 was intended for infrastructure management, while unifi-controller-01 had taken over responsibility for the UniFi Network Application.

The separation made sense to me.

I didn't want to repeat the arrangement I'd had with my old MacBook, where applications accumulated on the same machine simply because there was somewhere to install them.

So rather than installing Docker on the Proxmox host itself, or mixing general applications into one of the existing VMs, I created a third.

VM120 — docker-services-01

This would become the home for containerized applications that supported the lab and, potentially, services I might actually use around the house.

I was still getting comfortable with virtualization, and Docker introduced another layer of abstraction.

A physical machine could host virtual machines. Those virtual machines could each run their own operating systems. And one of those operating systems could host multiple applications in containers.

I understood the concept.

Getting accustomed to working with those layers was another matter.

The first permission problem

Docker's installation wasn't particularly troublesome.

Working with it initially was.

One of the first issues came from attempting to add the wrong Linux username to the Docker group. The account referenced in the command didn't actually exist on the VM.

Once that was corrected, I encountered another problem: permission denied when attempting to communicate with the Docker daemon.

It was a straightforward permissions and session issue, eventually resolved by correcting group membership and ensuring the session recognized the change.

But it was an early reminder that I needed to pay attention to the environment I was actually working in.

A command copied from a guide, or adapted from another machine, isn't necessarily appropriate for the system in front of you.

Even something as basic as a username matters.

There's also a security consideration here that became more apparent as I continued learning: membership in the Docker group provides powerful access to the host.

Convenience and privilege aren't entirely separate concerns.

With Docker functioning, I could finally get to the applications I wanted to run.

Portainer: a window into the containers

The first useful addition was Portainer Community Edition.

I wanted a graphical way to see what was running and manage containers without relying exclusively on commands.

Not because I wanted to avoid the command line, but because I was still learning how Docker organized containers, images, volumes and networks.

Portainer gave me a way to explore those relationships visually.

It was useful almost immediately.

But Portainer wasn't the dashboard I originally had in mind.

It provided a view of the container environment. I wanted a convenient starting page for the entire lab, including services that weren't running in Docker.

For that, I settled on Homepage.

A homepage that didn't want visitors

Homepage was intended to bring the environment together.

Proxmox, UniFi, Portainer, monitoring tools and other services could be presented as a single collection of links.

I liked the simplicity of the idea.

Rather than opening bookmarks or remembering addresses, I'd have one page that reflected what was available in the lab.

Except that getting the page to load correctly wasn't quite as straightforward as I'd expected.

Homepage was running, but requests using the address I was accessing it through were being rejected by its host validation.

I initially attempted to resolve the problem through the application's YAML configuration.

That didn't work.

After examining the container logs, the solution became clearer. The application expected the permitted hosts to be supplied through an environment variable:

HOMEPAGE_ALLOWED_HOSTS

I recreated the container with the appropriate configuration, and the dashboard became accessible.

This wasn't a particularly complicated problem once the correct configuration mechanism was understood.

But it was a useful introduction to something I'd encounter repeatedly with containerized applications.

An application can be running perfectly well inside a container while still being inaccessible or incorrectly configured from the user's perspective.

Docker had done its job by starting the process.

That didn't mean I'd finished mine.

Seeing whether things were actually available

Once the dashboard was working, another question arose.

What happens when one of those services stops responding?

A dashboard with links is useful, but clicking each one to see whether it works isn't much of a monitoring strategy.

So I deployed Uptime Kuma.

I began adding availability checks for Homepage, Portainer, Proxmox and UniFi.

At a glance, I could now see whether the selected service endpoints were responding.

It was satisfying to have a central dashboard and some basic visibility into availability.

But there was a distinction I would come to appreciate more as the lab evolved.

A successful availability check doesn't necessarily mean an application is healthy in every meaningful sense.

A web interface might respond while an important background function has failed. A container might be running while its application is unable to connect to a dependency.

And an application might appear perfectly healthy until someone actually tries to use it.

'Online' is a useful observation. It isn't a complete assessment.

Uptime Kuma gave me a starting point, not a complete monitoring solution.

That distinction would become increasingly important as the number of services grew.

Vaultwarden raised a different question

One of the applications I was interested in running was Vaultwarden, a self-hosted implementation compatible with Bitwarden clients.

This wasn't just another dashboard or experimental utility.

A password manager would potentially hold information I genuinely depended on.

And that changed how I needed to approach the deployment.

The container installed and reported a healthy state.

But that wasn't the same as being ready for use.

Vaultwarden required a secure browser context for important functionality, which meant I needed to resolve HTTPS properly before treating the deployment as suitable for real credentials.

I had an application that appeared to be operational, but I wasn't prepared to consider that a successful production deployment.

That was a useful boundary to establish.

I'd been treating most of the lab as an environment where I could install something, break it, rebuild it and move on.

That approach isn't quite so comfortable when the application is intended to protect passwords.

For the moment, Vaultwarden remained installed but not ready for that responsibility.

It would take more work on certificates and internal service access before I was comfortable moving forward.

Making addresses easier didn't make networking simpler

Another problem was beginning to emerge.

Every new service came with another address or port number to remember.

I wanted to type a recognizable name into the browser and arrive at the correct application.

So I introduced Nginx Proxy Manager.

The idea was to have a reverse proxy accept requests for different internal service names and direct them to the appropriate applications.

It was a sensible direction, but I was still missing part of the foundation.

I hadn't established proper internal DNS.

Instead, I began with temporary entries in my Windows hosts file to associate the names I wanted to use with the appropriate local address.

For testing, that worked.

But it wasn't a particularly elegant solution.

Those names existed because I had manually configured them on one computer. They weren't automatically available to every device in the household.

And not everything worked neatly through the proxy either.

Portainer, for example, remained accessible directly, but getting its reverse-proxy arrangement working correctly proved troublesome.

I had a collection of components that individually made sense:

• Homepage provided navigation.

• Portainer provided container administration.

• Uptime Kuma checked service availability.

• Nginx Proxy Manager provided a route towards simpler service access.

• Vaultwarden offered a potentially useful password-management service, once HTTPS was properly addressed.

What I didn't yet have was a fully coherent way to manage how those services were deployed, accessed, secured and recovered.

And I was starting to recognize the difference.

Five containers, several unfinished conversations

By this point, the lab was beginning to look rather impressive from the dashboard.

There were services to click, containers to inspect and status checks reporting results.

But the list of unresolved considerations was growing alongside the list of working applications.

What happened to application data if I removed a container?

How would I rebuild the environment without manually repeating every deployment?

What would happen after a Proxmox host failure?

Could I restore the applications, their settings and their data rather than simply reinstall the software?

How would I make internal names work consistently across different devices?

And how would I distinguish applications that were safe to experiment with from those I might eventually rely on?

These weren't necessarily questions I'd fully answered on 7 June.

They were the sorts of questions the environment was beginning to force me to confront.

I was enjoying building things, but I was also beginning to see how easily a lab could become another collection of loosely connected services.

Just with better-looking dashboards.

Moving beyond individual commands

The original Docker applications had been deployed using individual docker run commands.

That worked for getting started.

But it wasn't how I wanted to manage an expanding set of services indefinitely.

By 10 June, I had begun consolidating the Docker deployments using Docker Compose.

Instead of relying on a collection of individual commands, Compose provided a way to describe application deployments through configuration files.

That made the environment easier to understand and gave me a more repeatable basis for managing it.

Around the same time, I also began establishing more deliberate backup arrangements, including backups of the Docker VM and an archive of its application data and configuration.

There was still plenty to learn about restoration, and creating a backup isn't the same as proving that it can be restored successfully.

But the thinking was beginning to change.

The objective was no longer simply to get another application running.

It was becoming important to understand how that application fitted into the wider environment and what would be required to keep it operational.

I may have been moving a little too quickly

Looking back, I can appreciate how much I tried to accomplish in a relatively short period.

Within days of recovering an old Dell computer and installing Proxmox, I'd started building a virtualized network-management environment, a container platform, application dashboards, monitoring and the foundations of internal service discovery.

Each step had a reasonable explanation.

But collectively, I was introducing a fair amount of complexity before all the underlying arrangements had been properly established.

I don't necessarily regret that.

Part of the purpose of CMR Lab is to experiment, encounter problems and learn how different technologies fit together.

But there's a difference between experimentation and allowing an unfinished experiment to become something the household depends on.

That distinction would matter more as I began introducing services intended for everyday use.

For now, the Docker platform was operational, but not particularly mature.

The next challenge was to make service access more consistent, establish proper internal DNS and address HTTPS rather than continuing to work around those missing pieces.

And somewhere in all of that, I still wanted the original thing I'd asked for.

A simple webpage with links to my services.

This article is part of the CMR Lab engineering journal. Supporting architecture, implementation decisions and historical technical records are available in the CMR Lab GitHub repository.

status=4/ILL (Illegal Instruction)

That was it. The service would attempt to start and immediately fail.

I'd only just finished putting together my first Proxmox server, and one of the applications I wanted to run was already refusing to cooperate.

The interesting part was that the processor wasn't actually incapable of running the software. The problem was what the virtual machine thought the processor could do.

But I'm getting ahead of myself.

The first proper server

By 6 June 2026, the Dell OptiPlex 7010 I'd recovered was ready for its new role.

It had an Intel Core i7-3770, 20 GB of DDR3 memory, a 500 GB SSD and a 1 TB hard drive. Not exactly a modern server, but certainly enough to explore virtualisation and begin separating some of the services that had accumulated on my old Ubuntu MacBook.

I installed Proxmox VE 9.2.2 on the SSD.

The installation itself was fairly uneventful.

Once the web interface was accessible, I configured the no-subscription repositories, installed the available updates and rebooted to confirm everything returned as expected.

I also configured the BIOS to recover automatically after a power failure and prepared the machine to operate without a monitor or keyboard.

These weren't particularly exciting steps, but I wanted the basics right before depending on the machine for anything useful.

The secondary hard drive was brought into the storage configuration, and I was finally ready to create the first virtual machine.

Giving things their own place

The first VM was deliberately uncomplicated.

I created ubuntu-mgmt-01, assigned it two virtual CPUs, 4 GB of RAM and a 50 GB disk, then installed Ubuntu Server.

The idea was to have a dedicated management environment for infrastructure utilities and, eventually, automation.

It wasn't particularly difficult to get running. Ubuntu installed, networking worked, SSH was available and the QEMU Guest Agent was installed so Proxmox could better communicate with the guest.

I also created a snapshot of the fresh installation.

That last step felt like one of the immediate benefits of virtualisation.

I could experiment with software and configurations without necessarily having to rebuild an entire physical machine if something went badly wrong.

Of course, snapshots aren't backups, and I would eventually need to think much more seriously about recovery. But for the purpose of experimenting with a fresh operating system, it was a useful capability.

With the first VM running, the next question was what service to migrate.

UniFi seemed an obvious candidate.

One access point, too many possible controllers

My home network included a UniFi AC Pro access point.

It was working, but its management arrangement wasn't particularly satisfactory.

I had an older UniFi Cloud Key Gen1 that I'd managed to recover, reset and update. There was also a UniFi Network Controller running on my main Windows machine.

The Cloud Key was an option, but its age and limited upgrade path made me question whether it was the right place to continue investing time.

And I didn't particularly want the main PC responsible for managing the wireless network.

That was precisely the kind of arrangement I was trying to move away from.

So I decided to give UniFi its own VM.

unifi-controller-01 became VM110, running Ubuntu Server 24.04 with resources assigned specifically for the UniFi Network Application.

I liked the idea of this separation.

• VM100 — ubuntu-mgmt-01: General infrastructure management

• VM110 — unifi-controller-01: UniFi network administration

Each would have a clear responsibility.

At least, that was the intention.

Apparently, the processor couldn't follow instructions

Installing UniFi required a few supporting components, including Java and MongoDB.

MongoDB was where things stopped progressing.

The service failed with an illegal instruction error.

Initially, that suggested some sort of incompatibility with the processor. The OptiPlex was built around an ageing third-generation Intel Core i7, so it wasn't unreasonable to question whether its instruction set was sufficient.

But the processor supported AVX, which was relevant to the MongoDB version I was attempting to run.

The issue turned out to be how Proxmox was presenting the CPU to the virtual machine.

VM110 had been configured using the x86-64-v2-AES virtual CPU model.

That provided a standardized set of processor capabilities, but it did not expose the AVX instructions MongoDB needed.

In effect, the physical processor could support the software, but the virtual machine couldn't see the necessary capability.

I changed the VM's CPU type from x86-64-v2-AES to host.

MongoDB started successfully.

It was one of those problems that made considerably more sense after it had been resolved.

The error message wasn't necessarily misleading. The software really was encountering an instruction it couldn't execute in its presented environment.

What I'd initially considered a possible hardware limitation was actually a virtualization configuration issue.

I also came away with a better appreciation for why virtual CPU models matter.

Presenting a standardized CPU can be useful when moving virtual machines between hosts with different processors. Exposing the host's capabilities can offer better compatibility with certain workloads, but introduces its own portability considerations.

In my case, with a single Proxmox host at the time, changing to host was a reasonable decision.

More importantly, I understood why the change worked.

The application worked. The access point was another matter.

With MongoDB running, the UniFi Network Application installed successfully and its management interface became accessible.

That was encouraging.

The remaining task was to move the access point away from the controller on my Windows machine.

I'd already been dealing with a peculiar behaviour before the migration.

The access point would continue broadcasting Wi-Fi and supporting connected devices, but periodically disappear from the controller. Issuing a new set-inform command would restore its visibility.

I remember questioning why this seemed to happen almost every night.

The distinction was important. The wireless access point wasn't necessarily failing as a wireless device. Its communication with the controller was the part behaving unexpectedly.

Moving controller management onto a dedicated VM offered a cleaner arrangement, although it wasn't proof that the recurring behaviour would disappear.

I evaluated the existing controller backup and began preparing the new environment, including recreating the wireless network settings.

The access point initially appeared in the new controller, but the migration wasn't straightforward.

At one point, it required a reset.

I connected to the device and issued:

mca-cli-op set-default

That command reset the access point to its default state and closed the SSH connection, as expected.

What happened afterward was less convenient.

The access point was still visible on the local network. I could ping it, and the Linksys router showed it as a connected device.

Its LED was solid white.

But it wasn't appearing in the new UniFi controller, and the usual management connections weren't responding.

This was another useful distinction.

A successful ping told me the device was reachable at the network layer. It didn't tell me whether its management services were ready or whether it had established communication with the correct controller.

It was frustrating because the device was clearly there, but the application intended to manage it couldn't see it.

Eventually, I completed the migration and the AC Pro was successfully adopted into VM110.

The original controller on the Windows machine could finally be retired.

I enabled automatic startup for the management and UniFi virtual machines so they would return after the Proxmox host restarted.

The original objective had been achieved: the wireless controller now had a dedicated home on the virtualization platform.

Two problems, two different lessons

Looking back, the MongoDB and access point problems were quite different.

With MongoDB, I had a service that wouldn't run because the virtualisation layer was hiding a processor capability. The application logs pointed towards an instruction problem, and understanding the relationship between the guest CPU model and physical hardware led to a specific, successful correction.

With the access point, basic network connectivity wasn't enough to establish that controller communication was working.

A responding device and a manageable device aren't necessarily the same thing.

Both experiences reinforced something I wanted CMR Lab to help me develop: the discipline to separate what I've observed from what I've assumed.

• An error message is evidence, but it still needs interpretation.

• A successful ping is evidence, but it only answers a particular question.

• A configuration change that makes something work doesn't automatically establish every detail of the original cause.

By the end of the weekend

In a relatively short period, an ageing Dell OptiPlex had become an operational Proxmox server with separate virtual machines for management and wireless network administration.

There had already been a hardware recovery exercise, some storage configuration, a virtual CPU compatibility problem and an access point migration that was more awkward than I'd anticipated.

But the important thing was that the environment was beginning to make sense.

Instead of having services distributed across whichever machines happened to be available, I was beginning to assign responsibilities deliberately.

I also had a much better understanding of the systems supporting those services.

The next step was to build a separate Docker environment for the applications I actually wanted to run.

That would introduce another collection of decisions about containers, service access, storage, reverse proxies and which things should remain experiments rather than become dependencies.

For the moment, though, the first two virtual machines were doing their jobs.

And I'd already learned more than I expected from getting them there.

This article is part of the CMR Lab engineering journal. Supporting architecture, implementation decisions and historical technical records are available in the CMR Lab GitHub repository.

That was more or less where I found myself at the beginning of June 2026.

I had what I loosely considered a home lab. There was an ageing MacBook running Ubuntu Server, a collection of networking equipment, some Raspberry Pis and several computers that had either been repurposed or were waiting to be useful again.

Things worked. Mostly.

I had Jellyfin running, Cockpit for management, experiments with Ollama and a few other services that had accumulated over time.

But the environment wasn't particularly organized. Some things had been configured because I needed them at the time. Others existed because I wanted to experiment with something new.

I could make things work, but I couldn't necessarily claim that the environment had been designed with any real intention.

And increasingly, that bothered me.

A collection of experiments isn't necessarily a lab

I enjoy working with technology. Much of what I've learned throughout my career has come from working through problems, experimenting and figuring things out.

That curiosity doesn't switch off when I leave work.

Over time, the equipment I had available became an opportunity to explore things I might not ordinarily get to experiment with in a professional environment.

My old MacBook Pro, for example, had become an Ubuntu server. It wasn't particularly powerful: a dual-core Intel i5, 8 GB of memory and a modest SSD, supplemented by an external media drive.

It was also connected over Wi-Fi.

For a few services and occasional experiments, it was useful. But I was beginning to ask more of it than I had originally intended.

I wanted to explore virtualization, better network management, centralized DNS, automation, monitoring and eventually cybersecurity experimentation.

I also wanted documentation that was more meaningful than a collection of screenshots and notes I might struggle to find six months later.

The problem wasn't necessarily the equipment.

It was the absence of a coherent plan.

The temptation to start from scratch

My initial thought was to scrap the existing arrangement and rebuild everything.

New naming conventions. A better physical network. Clearly defined services. Proper documentation. A virtualization platform rather than another collection of applications running directly on whatever computer happened to be available.

I even started thinking about what new hardware might make the most sense.

But before committing to purchases, I decided to examine what I already had.

There were Dell OptiPlex machines, Lenovo laptops, two Raspberry Pis, a UniFi access point, a Cloud Key, a UniFi Security Gateway and various switches.

Some were operational. Some hadn't been used in a while. Others weren't even powering on properly.

And that became the first real exercise.

Instead of designing around what I wanted to buy, I would design around what I could actually make work.

The Dell OptiPlex that wasn't quite dead

One of the available systems was a Dell OptiPlex 7010 Small Form Factor.

It had seen better days.

When I began examining it on 3 June, it wasn't a functioning server candidate. I was dealing with an amber power indicator, diagnostic beeps and uncertainty about the condition of its components.

As it turned out, the machine initially had no memory installed.

After fitting a spare DDR3 module, I managed to get into the BIOS. The machine recognised the RAM and I could begin investigating the processor, storage and other components.

That was encouraging.

I had several old OptiPlex machines available, which meant I could recover parts rather than immediately purchasing replacements.

By 5 June, the system had come together.

It had an Intel Core i7-3770 processor, 20 GB of DDR3 memory, a 500 GB SSD and a 1 TB hard drive.

There was still a problem with one of the memory slots, but I had a working machine with enough resources to begin experimenting with virtualization.

It wasn't new, powerful or particularly elegant.

But it could do the job.

And there was something satisfying about that.

I had gone from investigating why an old computer wouldn't start to preparing it as the foundation of a completely rebuilt environment.

Sometimes the biggest improvement is a cable

There was another issue I needed to address before moving forward.

The internet connection entered the house downstairs. A CAT6 connection already ran to the Linksys router in the upstairs living room, where some of the networking equipment was located.

My lab equipment, however, was in a bedroom.

Rather than running another cable, I had been relying on Wi-Fi for convenience.

That was fine for ordinary use, but it wasn't how I wanted to operate a server hosting several persistent virtual machines and network services.

So I ran and terminated a CAT6 cable between the living-room networking equipment and the bedroom.

I tested the connection, brought a switch online and connected the main workstation and the newly recovered OptiPlex.

Nothing particularly sophisticated happened.

But suddenly I had a much more dependable physical foundation for the work ahead.

It also reminded me of something that is easy to overlook when you're excited about virtual machines, automation and security tools.

Sometimes the most important improvement is getting the basics right.

Getting serious about documentation

Around the same time, I began organising the project on GitHub.

This was another learning exercise in itself.

I'd worked with code and development tools before, but I hadn't developed a particularly disciplined approach to version control.

I was familiar with the problem of accumulating files called something along the lines of v1.0, v1.2, final and really final.

I didn't want my lab documentation to become another version of that.

So I began with a single repository and Markdown documents for the equipment inventory, architecture, decisions, roadmap and development history.

At first, even that felt a little excessive. I found myself creating files and wondering whether I was spending more time organising the project than actually building it.

That was a useful early lesson too.

Documentation needs a purpose.

I didn't need to manufacture an impressive-looking collection of documents. I needed enough structure to explain what existed, why I made decisions and what happened when something changed.

The documentation would evolve alongside the environment.

The first real milestone

By 6 June, the recovered OptiPlex was ready to become the first Proxmox server.

This marked the point where CMR Lab began transitioning from a collection of individual systems into something more deliberate.

The original MacBook had served its purpose, but it was no longer the right foundation for what I wanted to accomplish.

With Proxmox, I could begin separating responsibilities: management utilities, network administration and application hosting could each have their own environments.

At least, that was the plan.

I would soon discover that installing a virtualisation platform was only the beginning. Processor compatibility, storage configuration, application dependencies and networking would all introduce their own challenges.

Some of those problems would turn out to be considerably more interesting than the installations themselves.

Why I'm documenting this journey

CMR Lab isn't an attempt to build the most powerful home lab or collect the largest number of running services.

It's an opportunity to understand technology more deeply through practical experience.

I want to be able to explain not only what I've deployed, but why it was necessary, what alternatives I considered, what problems I encountered and how I determined whether something actually worked.

There will be mistakes, decisions I'll reconsider and experiments that don't go according to plan.

I'm not particularly interested in editing those parts out.

They're often where the learning happens.

And if documenting those experiences helps someone else approach a similar problem with a little more understanding, that's worthwhile too.

For now, the first milestone was relatively simple.

I had taken an unreliable collection of equipment, recovered an old computer, improved the physical network and established a foundation for the next stage.

I hadn't really started from scratch.

I'd started by understanding what I already had.

CMR Lab's technical architecture, decisions and supporting records are available in the GitHub repository.