Learn MicroCloud - Initialization: microcloud init

#Introduction

All snaps are installed from episode 3. Now comes the most anticipated moment: building the MicroCloud cluster with microcloud init on the first node. This command is the bridge from "three empty Ubuntu machines" to "one private cloud" — you just answer a few questions, and the LXD cluster, Ceph pool, and OVN network form automatically.

In episode 4 we dissect every choice init presents, why each choice exists, and how the result is verified. Get your first node ready — let's begin!

#Running microcloud init

#Starting from the First Node

Pick one node as the starting point (e.g., node-a) and run:

sudo microcloud init

MicroCloud will detect the environment and display an interactive wizard. The order of the questions is roughly:

1. Storage — which disks to use for Ceph OSDs, and whether there's a local dir.
2. Network — whether to use OVN, and which interface becomes the underlay.
3. Waiting for other nodes — scanning the network for nodes ready to join.

#Storage Choices

#Disks for Ceph OSDs

The first question usually asks you to select the disks that will become Ceph OSDs. MicroCloud shows the list of empty disks detected on the node:

Select disks for Ceph storage:
  /dev/sdb  500G   (empty)
  /dev/sdc  1.0T   (empty)
Use "/dev/sdb" for Ceph? (yes/no) [default=yes]

Select the empty disk you prepared in episode 3. This disk will be formatted and initialized as an OSD — this is the storage where instance volumes live and get replicated.

#Local Dir (Optional)

MicroCloud also offers a local dir — a directory on the system disk used for local (non-distributed) storage. The local dir is useful for instances that don't need HA, such as image caches or temporary instances. For production relying on HA, the Ceph disk remains the top priority.

Local storage dir? (yes/no) [default=yes]

Why does this option exist? Because not every workload needs replication. Ceph storage uses disk space × replication factor; local storage saves space and is faster for things that may be lost. This decision can be changed later through the LXD storage pool configuration (episode 6).

#Network Choices

#Bridge or OVN

After storage, MicroCloud asks about networking:

Setup OVN network? (yes/no) [default=yes]

• Yes (OVN): MicroOVN becomes active, and you'll be asked to choose the underlay interface (a physical NIC or an existing bridge). The OVN network is automatically registered with LXD as a cluster network.
• No: you use a regular LXD bridge without SDN — suitable for a minimal lab or when a flat network is enough.

To take full advantage of MicroCloud (a network that follows instances across nodes), choose Yes and point to an interface connected to the inter-node network. We dissect the SDN in episode 7.

Select an interface for the OVN underlay:
  eth0
  eth1

#Waiting for Other Nodes to Join

#Open Initialization Session

After the storage and network choices are done, MicroCloud waits for other nodes to join. It scans the network via mDNS to find nodes running microcloud join:

> Waiting for other nodes to join (CTRL+C to cancel)
  Scanning for servers on the network...

This is the point where you open another terminal on node-b and node-c and run microcloud join (episode 5). For single-node testing, let this process stop on its own (timeout) — MicroCloud will continue with just one node.

#Trust and Tokens

When other nodes join, MicroCloud validates trust. On version 2.1+ there's proactive trust — you can mark trusted peers before the join begins, so no manual approval is needed when nodes join (we cover this in episode 15). Without it, init will show the list of peers and ask for confirmation before integrating them.

#Result: Cluster, Pool, and Network Formed

#What Happens Automatically

Once all nodes have joined and the wizard completes, MicroCloud executes the entire configuration:

• An LXD cluster forms with all nodes as members.
• Ceph pools are created (default local-... for the local dir, and an RBD pool for instance storage).
• An OVN network is created and registered with LXD.

microcloud status

microcloud status shows a summary: cluster members, the OSD disks used, and the available networks.

#Verification at the LXD, Ceph, and OVN Layers

A cross-layer check ensures everything is consistent:

lxc cluster list

lxc storage list
lxc network list

microceph status
microovn status

All the commands above should show the cluster nodes. If a node is missing, repeat the checks and see the troubleshooting guide in episode 16.

#Common Pitfalls

• Init hangs on "Waiting for nodes": normal while waiting for peers; for single-node, let it time out or press CTRL+C once you're sure it's enough.
• Disk doesn't appear in the prompt: check lsblk — MicroCloud only shows truly empty disks; mounted or partitioned disks won't be offered.
• Wrong underlay chosen: picking a NIC not connected to the inter-node network will make OVN nonfunctional — check inter-node connectivity first (ping node-b).
• Running init repeatedly: if the cluster is already formed, re-initializing isn't recommended; use recovery (episode 16) instead of re-init.

#Closing

Key takeaways:

• microcloud init on the first node builds the entire cloud: LXD cluster, Ceph pool, and OVN network.
• Storage choices: an empty disk for Ceph OSDs + an optional local dir.
• Network choices: OVN (SDN) or a regular LXD bridge; choose the right underlay.
• Initialization waits for peers — other nodes join via microcloud join.
• Verify with microcloud status, lxc cluster list, microceph status, and microovn status.

In the next episode, we'll cover join: microcloud join — adding the second and third nodes to the cluster, multi-node scenarios, the trust/join token mechanism between members, and final verification with lxc cluster list, microceph status, and microovn status. Your cloud is starting to take shape!