Learn MicroCloud - Deploying Instances: Containers & VMs

#Introduction

Storage and networking are ready from episodes 6-7. Now comes the most satisfying part: running your first instances. In episode 8 we deploy system containers and VMs to the cluster, understand how LXD picks nodes, use Ceph storage, and leverage profiles for consistency. This is when your cloud truly starts serving workloads.

A simple analogy: an LXD cluster is like a hotel booking system. You approach the front desk (lxc launch) with a room request (instance specs); the front desk picks the best room (a node per scheduling), sets up standard amenities (profiles), and bills from the central warehouse (Ceph storage). The guest (instance) doesn't care which floor it's on — what matters is a stable address.

#Running Containers

#The First lxc launch

The basic command to create a system container:

lxc launch ubuntu:24.04 c1

LXD fetches the ubuntu:24.04 image from the remote image store, picks a node for c1, creates a Ceph storage volume for the root disk, connects to the OVN network, and starts it. A few seconds later:

lxc list

+----+---------+------+------+-----------+----------------+---------+
|NAME| STATUS  | TYPE |ARCH  |  SNAPSHOTS| IPV4           | LOCATION|
+----+---------+------+------+-----------+----------------+---------+
| c1 | RUNNING | container | x86_64 | 0 | 10.201.4.2    | node-b |
+----+---------+------+------+-----------+----------------+---------+

Notice the LOCATION column: c1 runs on node-b, even though you executed the command from any node. This is what an LXD cluster means — commands can be run from any member and LXD schedules instances across the whole cluster.

#Accessing the Container

lxc exec c1 -- bash

Or run a command directly without entering:

lxc exec c1 -- hostname

#The Ceph Storage Pool for Instances

#MicroCloud's Default Pool

During init, MicroCloud creates the storage pool for instances in LXD:

lxc storage list

+------------------+--------+----------+-------------------+------+------+
|      NAME        | DRIVER |  SOURCE  |     DESCRIPTION   | ...  |
+------------------+--------+----------+-------------------+------+------+
| local            | dir    | /var/snap/lxd/common/... | |     |
| remote           | ceph   | remote   | Ceph pool         |      |
+------------------+--------+----------+-------------------+------+------+

• remote (driver ceph) — the RBD pool in MicroCeph, the primary storage for instances that need HA.
• local (driver dir) — a directory on the node's local disk, for things that don't need replication.

#Choosing a Pool per Instance

By default the MicroCloud profile points at the Ceph pool. If you want to be explicit:

lxc launch ubuntu:24.04 c2 --storage remote

lxc storage volume show remote c2

#Running VMs

#lxc launch with --vm

For workloads that need their own kernel (special kernel modules, software that refuses containers), deploy a VM:

lxc launch ubuntu:24.04 v1 --vm

LXD boots the VM with QEMU/KVM, uses the cloud image with cloud-init, and connects it to the same network. From the network side, VMs and containers coexist on the same logical switch.

lxc list v1
lxc info v1

#VMs and Live Migration

One of the main reasons to choose VMs in MicroCloud: live migration. A VM running on the Ceph pool can be moved to another node without downtime:

lxc move v1 --target node-c

Because the VM's root disk lives on Ceph (accessible from any node) and its network is the OVN overlay (stable IP), migration only moves CPU execution — the guest feels nothing. This is the operational foundation we use for HA in episode 9.

#Default Profile and Custom Profiles

#MicroCloud's Default Profile

MicroCloud creates a default profile that binds storage and network:

lxc profile show default

config:
  cloud-init.user-data: |
    #cloud-config
    ...
devices:
  eth0:
    name: eth0
    network: default
    type: nic
  root:
    pool: remote
    size: 10GiB
    type: disk

Every instance launched without a custom profile inherits these settings: the default OVN network and a root disk on the remote Ceph pool. This is why lxc launch ubuntu:24.04 c1 immediately "becomes the cloud".

#Custom Profiles for Special Workloads

For resource or device variations, create your own profile:

lxc profile create web
lxc profile set web limits.cpu 2
lxc profile set web limits.memory 4GiB

lxc launch ubuntu:24.04 web1 --profile default --profile web

Profiles can be combined — default provides storage/network, web adds resource limits. Already-running instances can also have their profiles updated:

lxc profile assign web1 default,web

#Common Pitfalls

• Instance accidentally "stuck" on one node: check whether the instance uses the Ceph pool; local storage pins an instance to its node.
• VM fails to boot: make sure the cloud image and KVM support exist on all nodes (lxc info --resources), and limits.cpu is sufficient.
• Image not found: the LXD remote image must be reachable; in offline environments, copy the image to the storage pool first.
• Live migration fails: the VM must be based on Ceph storage and its state (agent) must be compatible — check lxc config show v1 for migration.stateful.

#Closing

Key takeaways:

• lxc launch ubuntu:24.04 c1 creates a system container that automatically joins the cluster, Ceph storage, and OVN network.
• The remote (Ceph) pool is for HA; the local pool is only for things that may be lost.
• VMs with --vm support live migration via lxc move --target.
• MicroCloud's default profile unifies storage + network; custom profiles add resource limits.
• LXD commands run from any member — the cluster handles scheduling.

In the next episode, we'll cover high availability & failover — how instances are automatically rescheduled when a node goes down, how Ceph replication protects data, and a drill simulating a dead node then verifying automatic recovery. This is the real test for your cloud!