Charmed OpenStack is Canonical’s model-driven way of standing up an OpenStack cloud — MAAS for the metal, Juju for the orchestration, and charms for everything in between. It removes a great deal of the manual labor. It does not remove your responsibility for the data that ends up running on top of it.
Table of Contents
OpenStack has a deserved reputation. It is one of the most capable open-source platforms for running a private cloud, and one of the most components-heavy projects in existence — several dozen services that all have to agree with each other before a single instance boots. Canonical’s answer to that complexity is Charmed OpenStack: don’t configure the cloud by hand, model it.
This article covers what Charmed OpenStack actually is, the three tools that make it work, where it differs from Canonical’s newer Sunbeam approach, and — because someone eventually has to ask the uncomfortable question — how you back the whole thing up without putting agents inside your instances or reaching into the hypervisor.
What Charmed OpenStack actually is
Charmed OpenStack is an implementation of OpenStack built on Canonical’s tooling: MAAS, Juju, and charms. Instead of installing Keystone, Nova, Neutron, Glance and the rest one package at a time, you describe the cloud as a set of services and the relations between them. Juju then deploys those services, wires them together, and manages their lifecycle.
The three layers each do one job:MAAS – Metal as a Service — provisions and PXE-boots bare-metal nodes, installs the OS, tags hardware by role.Juju – Models the cloud, deploys services, defines relations, and manages scaling and upgrades.Charms – Encapsulated operators — one charm per service (e.g. nova-compute), carrying its deploy and config logic.Bundle – openstack-base — a curated set of charms and relations that stands up a reference cloud.
The architecture below shows how those layers stack — from the metal at the bottom to the OpenStack control plane and the Ceph storage tier on top.
Fig 1. The Charmed OpenStack stack — MAAS provisions the metal, Juju orchestrates, charms encapsulate each service, and the OpenStack control plane runs on top.
The three pillars, in one sentence each
MAAS turns a rack of anonymous servers into a pool of addressable, role-tagged nodes Juju can deploy onto. Juju is the part that does the thinking — you declare what you want and how the pieces relate, and it builds the graph. Charms are where the operational knowledge lives: each one knows how to install, configure, relate, scale, and upgrade its service, so the cloud administrator does not have to hold all of that in their head at 2 a.m.
Upgrades are part of the model too. Canonical ships the Charmed OpenStack Upgrader (COU), which detects the running cloud version and proposes a path to the next release — a meaningful detail, because in-place OpenStack upgrades are precisely the operation most teams put off until something forces their hand.
Charmed OpenStack vs. Sunbeam — don’t conflate them
One distinction worth getting right, because it changes how you plan everything downstream: “Canonical OpenStack” today refers to two different deployment models.
Two roads, same destination. Charmed OpenStack uses machine charms on Juju and MAAS — the mature, widely deployed model described in this article. Sunbeam is the newer, Kubernetes-native approach (K8s operators) positioned as the next-generation Canonical OpenStack. They are not interchangeable, and your operational tooling, storage assumptions, and data-protection design differ between them. When someone says “Canonical OpenStack,” ask which one.
The good news for either choice: the backup approach below supports both — Charmed OpenStack 2024.1 and Sunbeam 2024.1 LTS — so the deployment model you pick does not dictate how you protect the cloud.
Why backing up Charmed OpenStack is its own problem
Here is the part vendors tend to skip past. Charmed OpenStack automates deployment beautifully. It does not, on its own, protect the workloads running inside the instances — and an OpenStack cloud is a multi-component, multi-tenant, Ceph-backed environment where “just snapshot the VM” is rarely the whole answer.
A backup approach for this platform has to satisfy three constraints at once: it must not put agents inside the guest instances or reach into the hypervisor OS — both are overhead and privileged access you would rather not grant; it must drive the backup through OpenStack’s own APIs — Cinder for snapshots, Nova and Glance for metadata; and it must handle incremental backups across whatever storage backend the cloud happens to use, Ceph RBD included.
This is the architecture Storware Backup and Recovery uses. The data flow looks like this:
Fig 2. Storware takes a crash-consistent snapshot through the Cinder API, attaches the resulting volume to a Proxy VM in the Availability Zone, and reads the data there — optionally pulling changed-block lists from the Ceph monitors for incrementals. No agents in the guest VMs, no hypervisor OS access.
The mechanics, for the engineers in the room: Storware takes a crash-consistent snapshot through the Cinder API and collects instance metadata from the Nova, Glance and Cinder APIs. Volumes created from that snapshot are attached, one at a time, to a Storware Proxy VM running in the Availability Zone, and the data is read there — no agent inside the guest, and no access to the hypervisor OS. Application consistency is available through optional pre/post-snapshot command execution. For incrementals you have two options: where Ceph RBD is the storage backend, Storware fetches the changed-block list directly from the Ceph monitors (CBT-like); the preferred, backend-independent option computes block-level checksums, so incrementals work on any storage at the cost of a little more compute. Restore recreates the volumes on the Proxy VM, rebuilds the instance, and reuses the Glance image when it already exists in the target environment.
Two backup strategies, picked to fit your storage
Charmed OpenStack environments don’t all store disks the same way, so a single approach would be a poor fit. Storware exposes two production strategies — both built on Cinder disk-attachment — and which one you choose comes down to your storage backend and how much you care about backend-independent incrementals.
Fig 3. Both strategies use Cinder disk-attachment and never touch the hypervisor OS. Pick Disk attachment for CBT-like incrementals on Ceph; pick Generic incremental — the preferred option — when you want backend-independent incrementals with nothing more than API access.
What you get on top of the data path
The transport layer is only half the value. Around it sits the part that matters when something goes wrong: an agentless architecture so neither the guest instances nor the hypervisor OS carry backup software, IsoLayer air-gap and WORM immutability with retention lock to keep copies beyond reach of ransomware, a Horizon UI plugin so tenants and administrators manage backups inside the dashboard they already use, a RESTful API for policy-driven automation, and multi-tenant RBAC for service-provider and enterprise separation.
Licensing is deliberately boring, which is the highest compliment you can pay an enterprise license model: per VM, per host, or per TB, with a single license covering every supported hypervisor — so a heterogeneous estate doesn’t turn into a procurement project every time you add a platform. And if part of that estate is still on VMware, the same platform handles VMware-to-OpenStack V2V migration, which makes Charmed OpenStack a realistic consolidation target rather than a science project.
The honest summary. Charmed OpenStack solves deployment and lifecycle. It does not solve data protection — that remains your problem, and a multi-component, Ceph-backed, multi-tenant cloud is not a place to improvise. An agentless, policy-driven backup layer that drives everything through Cinder, Nova and Glance — and handles incrementals on any storage backend — is the proven way to close that gap.
Frequently asked questions
What is Charmed OpenStack?
Charmed OpenStack is Canonical’s model-driven implementation of OpenStack. It uses MAAS to provision bare-metal servers, Juju to orchestrate deployment and lifecycle, and charms — encapsulated operators, one per service — to deploy and manage each OpenStack component such as Nova, Neutron, Keystone and Glance.
What is the difference between Charmed OpenStack and Sunbeam?
Charmed OpenStack uses machine charms on Juju and MAAS and is the mature, widely deployed model. Sunbeam is Canonical’s newer, Kubernetes-native deployment approach using K8s operators. They have different operational tooling and storage assumptions, so data-protection and infrastructure planning differ between them. Storware’s disk-attachment strategies support both — Charmed OpenStack 2024.1 and Sunbeam 2024.1 LTS.
How do you back up a Charmed OpenStack cloud?
The agentless approach Storware Backup and Recovery uses takes a crash-consistent snapshot through the Cinder API and collects metadata from the Nova, Glance and Cinder APIs. Volumes created from the snapshot are attached to a Storware Proxy VM running in the Availability Zone, and the data is read there — no agent inside the guest instances and no access to the hypervisor OS. Both full and incremental backups are supported.
Which backup strategy should I use for Charmed OpenStack?
There are two Cinder disk-attachment strategies. Disk attachment supports full backups, plus CBT-like incrementals when the storage backend is Ceph RBD (changed-block lists fetched from the Ceph monitors). Disk attachment with generic incremental is the preferred option: it computes block-level checksums so incrementals work regardless of the storage backend and needs only the OpenStack APIs, at the cost of slightly more compute.
Does backing up Charmed OpenStack require agents on compute nodes?
No. The architecture is agentless and works entirely through the OpenStack APIs and a Storware Proxy VM in each Availability Zone. No backup agent runs inside the guest instances, and no access to the hypervisor OS is required.
Protect your Charmed OpenStack cloud — agentless, proven, policy-driven
See how Storware Backup and Recovery protects your Canonical OpenStack estate through Cinder disk-attachment, with backend-independent incrementals and immutable, air-gapped destinations. Book a technical walkthrough →
