A senior engineer’s take on the real-world challenges of running Canonical’s MicroCloud in production, with practical solutions for networking, storage, and knowing when to use a different tool for the job.

So You Want to Run MicroCloud at Scale? Let’s Talk.

I remember the day the request came in. “Hey Darian, can you spin up that MicroCloud thing for the new AI dev team? They just need a small lab.” Famous last words. A week later, their “small lab” was running a critical model training pipeline, and my boss was asking me how we could get a dozen more nodes with direct access to our SAN and a public-facing VLAN. I just stared at the simple, beautiful, but incredibly rigid cluster I had set up in 30 minutes and thought, “Well, this just got complicated.”

The Core Problem: Opinionated by Design

Let’s get one thing straight: MicroCloud isn’t broken. It does exactly what it says on the tin. It’s an incredibly fast way to get a self-contained, private cloud up and running. Canonical made a bunch of design decisions for you—using LXD, OVN for networking, a simple LVM storage pool—all in the name of simplicity. The “problem” arises when those decisions don’t align with the complex, messy reality of an established enterprise environment. When you try to run it “at scale,” you’re not just adding nodes; you’re fighting against the very simplicity that makes it so appealing in the first place.

Fix #1: The Quick Fix (The “Cluster in a Box” Method)

This is the path of least resistance. You treat the MicroCloud cluster as a black box with one network pipe to the outside world. Don’t fight its internal networking; just work around it.

We did this for a while. The entire cluster (say, mc-node-01 to mc-node-05) lived on its own isolated VLAN. The instances inside got their 192.168.x.x addresses from the internal OVN network. To expose services, we didn’t try to give instances public IPs. Instead, we put a dedicated HAProxy or Nginx load balancer outside the cluster and had it forward traffic to the internal IPs of the instances.

When to use this:

• For self-contained development or test environments.
• When you only need to expose a few web services (APIs, frontends).
• When you absolutely, positively cannot get the network team to give you a dedicated routable subnet.

Warning: This is a workaround, not a scalable architecture. You create a bottleneck at your load balancer, and any service that isn’t simple HTTP/S traffic becomes a massive headache to configure.

Fix #2: The Permanent Fix (Surgical Integration)

This is where you roll up your sleeves and perform surgery on the defaults. You’re going to tell MicroCloud how to talk to your existing infrastructure. This is the path we eventually had to take.

Step A: Fix the Storage First

Never, ever run the default loop-based storage in production. It’s slow and dangerous. When you initialize your cluster, you need to point it to real, dedicated block devices. If you have a free disk (e.g., /dev/sdb) on all your prospective nodes, you can do this during initialization.

# This is an interactive process!
# Run this on your FIRST node to create the cluster.
microcloud init

# During the prompts, when asked about storage,
# DO NOT accept the default.
# Choose to create a new LVM pool and specify '/dev/sdb'
# or whatever your dedicated device is.

Step B: Fix the Networking

The default “fan” overlay network is great for getting started, but it’s not going to cut it for production. You need your instances to be first-class citizens on your real networks. We can achieve this by creating a new LXD network that bridges to a physical NIC on the host.

Let’s say your host’s eth1 is connected to your corporate “services” VLAN (VLAN 101). We can create a bridge that lets instances talk directly on that network.

# This tells LXD (which powers MicroCloud) to create a new network
# called 'corp-net' that bridges to the host's eth1 interface.
lxc network create corp-net --type=bridge parent=eth1

# Now, you can launch an instance directly on that network
lxc launch ubuntu:22.04 my-prod-app --network=corp-net

The instance my-prod-app will now get an IP from the DHCP server on your VLAN 101, just like any physical server would. It’s fully integrated.

Fix #3: The “Nuclear” Option (Know When to Fold ‘Em)

I have to be honest. There’s a point where you’re spending more time fighting MicroCloud’s opinions than benefiting from its convenience. If your needs are highly specific, MicroCloud might be the wrong tool for the job. You’re not failing; you’re making a sound architectural decision.

My rule of thumb is this: if you find yourself needing to bypass more than two of its major components (e.g., you want to replace OVN with something else *and* use a custom Ceph cluster you already have), it’s time to stop.

Here’s a quick guide on when to stick with it and when to bail:

In the end, we made our “critical” MicroCloud cluster work using the surgical approach. But for the next big project, which had even more stringent networking demands, we opted to build a vanilla LXD cluster with Ansible. It took more work up front, but we weren’t fighting the tool every step of the way. MicroCloud is a fantastic piece of engineering, but a good engineer knows that the best tool is the one that fits the job, not the one that’s trending on Reddit.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions