Part One
A House of Her Own
Chapter 1
Bitsy Needs a Whole House
Once upon a time there was a little app named Bitsy. Bitsy was not fussy, but she was particular: she didn't just want a room of her own — she wanted a whole house. Her own kitchen, her own plumbing, her own front door. In grown-up words: her own operating system, her own kernel, her own machine.
But Bitsy lived squeezed onto one big physical server with lots of other apps she didn't know. When one neighbor got greedy with the CPU, everyone's soup went cold. When another crashed, the whole shelf shook. Bitsy sighed a very small sigh. "There has to be a better way to get a house."
What's really going on
Virtual machines & hypervisors
A virtual machine (VM) — CloudStack calls a running one an instance — is a complete "house": virtual CPU, memory, disk, and network with its own guest operating system inside. Unlike a container, which shares the host's kernel, a VM brings the whole environment with it.
VMs live on physical servers running a hypervisor. Apache CloudStack can manage many hypervisor types side by side — KVM, VMware vSphere, XenServer/XCP-ng, Hyper-V, and more — plus bare metal, all from one place.
Chapter 2
Monty the CloudMonkey
One breezy morning, a monkey in a little blue cap swung down from a cloud. "Hello, friend app! My name is Monty. I keep the Great Cloud Tree."
Monty carried an enormous ledger. In it he had written down every treehouse, every branch, every cupboard, and exactly who lived where. When anyone wanted a house — one house or ten thousand — they simply asked Monty, and Monty arranged everything. He never built the houses with his own paws; he orchestrated, which is a fancy word for being extremely organized on everyone else's behalf.
What's really going on
The Management Server
The CloudStack Management Server is Monty: the orchestration brain of the cloud. It serves the web UI and the CloudStack API, assigns instances to hosts, allocates storage and IP addresses, and manages every resource in the deployment — while keeping its "ledger," the state of the whole cloud, in a MySQL database.
It runs as a Java service on its own machine (or several, clustered behind a load balancer for scale and resilience) and never runs your workloads itself — it directs the hosts that do. Users, admins, and tools like CloudMonkey (cmk), Terraform, or Ansible all talk to the same API.
Chapter 3
A Tour of the Great Cloud Tree
Monty took Bitsy on a tour. "The forest is enormous," he said, "so we keep it tidy. The whole forest is a Region. Each giant tree is a Zone — its own grove with its own power and its own weather. A Zone's big limbs are Pods. On each limb, treehouses that are built exactly alike huddle together in Clusters. And each treehouse is a Host — that's where little apps actually live."
Bitsy's eyes went wide. "So if a storm hits one tree…" — "…the other trees don't even get wet," Monty finished, looking rather pleased.
What's really going on
The deployment hierarchy
CloudStack organizes infrastructure in nested layers:
- Region — the largest unit: a geographic collection of zones served by its own management server cluster.
- Zone — typically one datacenter (or a room in one), with its own power and network uplink; the unit of visibility users pick when deploying. Zones give fault isolation and redundancy.
- Pod — usually a rack (or row of racks) with its own layer-2 switch and one or more clusters; hosts in a pod share the same subnet.
- Cluster — a group of identical hosts running the same hypervisor, sharing primary storage — the natural boundary for live migration.
- Host — a single hypervisor server where instances actually run.
Chapter 4
The Blueprint Book
"Now," said Monty, opening a beautiful book of glowing blueprints, "what kind of house would you like? Every page here is a finished house we can copy perfectly, as many times as you please — furniture, wallpaper, and all."
Some blueprints were plain and sturdy. Some came with the cupboards already stocked. And if Bitsy ever wanted to build a house completely from scratch, Monty had shiny installation discs for that too. Bitsy picked a cozy blueprint with a round window, and before she finished saying "that one, please," her house had already sprouted on a branch.
What's really going on
Templates & ISOs
A template is a reusable base image for an instance: an operating system, optionally with applications pre-installed. Deploying from a template stamps out a fully working machine in moments, and any instance can be turned back into a new template — furniture and all.
An ISO is the "installation disc" path: attach a bootable image and install the OS yourself. CloudStack ships with built-in templates, and users can upload or register their own, share them, or keep them private. Fresh copies are delivered to wherever they're needed from the zone's secondary storage.
Chapter 5
How Many Rooms?
"And how many rooms?" asked Monty. "A snug one-room house? A grand one with a fast pantry and a wide driveway?" Bitsy looked at the menu. Houses came in tidy fixed sizes, and Monty could even craft a custom size if she asked nicely. He also mentioned, in a slightly quieter voice, that bigger houses cost more acorns — the forest kept careful count of who used what.
What's really going on
Service offerings
A compute offering defines the "size" of an instance: number of vCPUs, CPU speed, and RAM, plus extras like network rate and storage tags. A disk offering does the same for additional data volumes, and system and network offerings define the sizes and capabilities of the cloud's own machinery.
Offerings are how an admin shapes the menu users choose from — including custom (user-sized) offerings — and they feed CloudStack's usage records, so every acorn of CPU, RAM, and disk can be metered and billed.
Part Two
How the Tree Works
Chapter 6
The Chest and the Barn
Bitsy had things. All apps do. "Where do I keep my things?" she asked. Monty pointed at two places. "Your everyday things — the rooms of your house itself — live in the chest right here on the branch, shared by your cluster of treehouses. It's fast, because it's close."
"And down at the roots is the great barn, one for the whole grove. That's where we keep the blueprint book, the installation discs, and photographs of houses. It's bigger and calmer, and every branch can reach it."
What's really going on
Primary & secondary storage
Primary storage holds the running disk volumes (root and data) of instances. It's typically shared at the cluster level — NFS, iSCSI, Fibre Channel, Ceph/RBD, or local disk, depending on hypervisor — and it sits close to the hosts because instances read and write to it constantly. It can also be added zone-wide.
Secondary storage is zone-level shelf space for templates, ISOs, and volume snapshots — usually NFS or S3-compatible object storage. Instances don't run from it; it's the library everything is copied out of and archived into.
Chapter 7
Monty's Tireless Helpers
Monty, it turned out, had helpers — quiet, dependable ones he raised himself. Pip the parrot flew all day between the barn at the roots and the branches, delivering fresh blueprints and carrying photographs back down for safekeeping.
And on every grove hung a magic porthole. Peer into it from anywhere in the world, and you could see right inside your own house and tidy up — even if your house's doorbell was broken. "I made these helpers the same way I make everything," Monty said. "If one gets tired, I simply grow a fresh one."
What's really going on
System VMs
CloudStack runs parts of itself as special instances built from a dedicated system VM template, created and healed automatically by the management server:
- Secondary Storage VM (SSVM) — Pip: moves templates, ISOs, and snapshots between secondary storage, primary storage, and the outside world (uploads/downloads).
- Console Proxy VM (CPVM) — the porthole: streams instance consoles into your browser, so you can reach a machine even when its own network is misbehaving.
- Virtual Router — the third helper, important enough to meet properly on the next page.
Chapter 8
Vera and the Fenced Garden
Bitsy's favorite helper was Vera the Virtual Router, a brisk blue bird who appeared the moment Bitsy's garden did. Vera handed every new house its own address, forwarded letters, kept a sharp eye on the one gate in the garden fence, and turned away strangers who hadn't been invited.
"Inside your fence, your houses can chat freely," Vera chirped. "To the outside world, the whole garden looks like one front gate — and nobody gets in unless you say so." Bitsy, who remembered the crowded old shelf all too well, thought a private garden with a professional gatekeeper was just about the loveliest idea she'd ever heard.
What's really going on
The Virtual Router & guest networks
When a user's first instance starts in an isolated network, CloudStack spins up a Virtual Router for it. Depending on the network offering it provides DHCP, DNS, source NAT, firewall rules, port forwarding, load balancing, static NAT, and VPN — Vera's whole job description.
Guest networks come in flavors: isolated (private per account, one "gate" of public IPs via NAT), shared (one network many tenants use, typically VLAN-backed by the admin), and L2 (bring-your-own addressing). A VPC groups multiple isolated tiers behind one VPC router with ACLs between them — a garden with several beds and one very organized gatekeeper. Redundant router pairs are available for the safety-minded.
Chapter 9
Say Cheese!
One evening Bitsy asked a worried question: "Monty… what if I break something in my house? What if I spill jam on absolutely everything?"
Monty produced a camera. "Say cheese." Click. "Now if anything goes wrong, we open the album in the barn and put your rooms back exactly as they were tonight. I can even take a photo every evening while you sleep, if you like. And from your favorite photo, we can grow a brand-new house — or a whole street of them."
What's really going on
Volumes & snapshots
An instance's disks are volumes — one root volume, plus any data volumes you attach. A snapshot is a point-in-time copy of a volume, kept on secondary storage, and can be taken on demand or on a recurring schedule with retention policies.
From a snapshot you can restore, create a new volume, or build a new template — which is exactly how one well-jammed house becomes a fresh street of clean ones. (VM snapshots, which capture a whole running instance including memory on supported hypervisors, are the deluxe version of the trick.)
Chapter 10
The Storm
Then one afternoon, a real storm came. A branch cracked. Bitsy's treehouse groaned and went dark. But before she could even be properly frightened, strong paws scooped her up, and — whoosh! — she was zipping along a line to a healthy treehouse two branches over, kettle, cupboards, photographs and all.
"Your things were never in the treehouse, remember?" Monty said, catching his breath. "They're in the chest the whole cluster shares. Any matching treehouse can be your house in a blink. On calm days I can move you while you're mid-tea and you won't spill a drop."
What's really going on
High availability & live migration
Because instance volumes live on shared primary storage, an instance isn't welded to one host. Deploy from an HA-enabled offering and CloudStack will automatically restart your instance on a healthy host in the cluster if its host fails. Host HA goes further for KVM, fencing and recovering the failed host itself (with help from out-of-band management like IPMI).
Live migration is the calm-weather version: the admin moves a running instance between hosts — for maintenance, patching, or balance — with no downtime. Storage can migrate too. This is why clusters are made of matching treehouses.
Part Three
Running a Tidy Tree
Chapter 11
Fenced Neighborhoods
By now Bitsy had noticed something wonderful. The Great Cloud Tree was full — families of apps on every limb — yet it never once felt like the crowded old shelf. Every family had its own fenced garden, its own acorn allowance, and its own key. Neighborhoods of families kept their own rules, and Monty made sure nobody could peek over anyone's fence, not even by accident.
Some families even shared a community garden for projects they tended together. It was, Bitsy decided, exactly how a tree should be run.
What's really going on
Domains, accounts & projects (multi-tenancy)
An account is the basic tenant — a customer or team — containing one or more users who share its resources; isolation happens between accounts. Accounts are grouped into hierarchical domains, each of which can have its own delegated admins, resource limits, and offerings.
Projects are the community gardens: shared spaces where members of different accounts collaborate on resources tracked and billed together. Roles control exactly which API calls each user may make. That's how one cloud serves many tenants who never trip over each other.
Chapter 12
The Jam Window
Bitsy's raspberry jam, it must be said, became famous. Apps from far-away trees wanted to try it. But Vera would not simply fling the gate open. "Rules are rules," she said, producing a guest list. "I shall open exactly one shutter — window 80, the jam window. Visitors may knock there and nowhere else. Every other shutter stays latched unless you put it on the list."
A baker friend who ran a very busy house asked Vera for a private gate all of her own, and got one — every knock on that gate went straight to her door. And in the wide-open meadows where there was no big fence at all, Monty gave each house its own little picket fence that walked along with the house wherever it moved. Bitsy thought that was both sensible and adorable.
What's really going on
Firewall rules, port forwarding & security groups
In an isolated network, public IPs start closed. A firewall rule opens a port on a public IP, and a port forwarding rule sends that traffic to a specific instance and port — window 80, the jam window. Static NAT maps one public IP one-to-one to a single instance (the baker's private gate), and load balancing rules on the Virtual Router spread visitors across several houses. Egress rules control who may go out, too.
Security groups are the traveling picket fences: per-instance ingress/egress filters used in shared networks (and security-group-enabled zones) where there's no Virtual Router gate to hide behind. By default they deny incoming and allow outgoing traffic, and rules can reference other groups — "let anyone from the bakers' group knock."
Chapter 13
The Acorn Allowance
One morning Bitsy met a new member of Monty's staff: Tally, a squirrel with reading glasses and the tidiest abacus in the forest. Tally kept a jar of acorns for every family, with a label that said exactly how many houses, gates, chests, and photographs each family was allowed. "Not because we're stingy," Tally explained, "but because a tree where one family takes every branch is a tree where nobody else can live."
If a family truly needed more, they could ask their neighborhood elder — or Monty himself — and the label on the jar would be rewritten. Bitsy checked her own jar. Twenty houses allowed, four used. "Room to grow," she said happily, and Tally almost smiled.
What's really going on
Resource limits & quotas
Resource limits cap what each account, domain, or project may consume: instances, public IPs, volumes, snapshots, templates, networks, VPCs, CPU cores, memory, and primary/secondary storage space. Global settings (the max.account.* and max.project.* family) set the defaults; admins override per account or domain, and a value of -1 means unlimited. Domain limits cap everything beneath them, so a delegated admin can subdivide their own allowance.
The optional Quota plugin goes a step further and prices consumption in credits or currency, drawing on usage data — which is exactly what Tally is counting on the next page.
Chapter 14
Tally's Night Rounds
Late one night Bitsy woke for a glass of water and spotted a lantern bobbing between the branches. It was Tally, tiptoeing from house to house with a notebook, reading the tiny meters by each door. How long was this house awake today? How many letters went through that gate? How much of the chest is this family using? Scratch, scratch, went the pencil.
"Monty writes down what happens," Tally whispered, "and once a day I turn his happenings into proper sums. Then the families who run the tree know exactly what to put on each bill — down to the hour and the acorn." Bitsy, who found sums soothing, went back to bed entirely reassured.
What's really going on
The Usage Server & usage records
The Usage Server is an optional, separately installed service (cloudstack-usage) that turns CloudStack's raw events into billable usage records in its own usage database. On a schedule (the aggregation range, daily by default, configured with usage.stats.job.* settings) it tallies per account: running and allocated instance-hours, IP address-hours, network bytes sent/received, volume, template, ISO and snapshot storage, load balancer and port forwarding rule-hours, VM snapshots, and backups.
Query results with the listUsageRecords API and feed them to your billing system — CloudStack meters everything but deliberately leaves pricing and invoicing to you (or to the Quota plugin, if you want it handled in-house).
Chapter 15
The Town Book and the Bell
Nothing happened in the Great Cloud Tree without being written in the town book. "Bitsy grew a house, seven past nine. The Fern family took a photograph, quarter past ten." Anyone could look up their own page whenever they liked, which settled a surprising number of arguments before they started.
And up on the trunk hung a brass bell. When something needed a grown-up — a chest nearly full, a helper feeling poorly, a branch running out of room — the bell went ding! and a letter flew to the tree's caretakers before the echo faded. For especially curious neighbors, Monty could even repeat the news through a megaphone to other forests, so their own machines could listen and act.
What's really going on
Events, alerts & notifications
CloudStack records an event for virtually every action — user API calls, scheduled jobs, state changes — browsable in the UI and via listEvents. Alerts are the bell: raised when capacity crosses thresholds, system VMs misbehave, hosts disconnect, or the usage server misses a beat; the management server can email administrators via SMTP, and listAlerts shows them all.
For machines that want the news too, the event bus can publish every event to RabbitMQ or Kafka, and webhooks can POST events straight to your own endpoints — the megaphone to other forests.
Part Four
A Tree That Grows
Chapter 16
The Jam Rush
Then came the Jam Festival, and the queue at window 80 wrapped twice around the branch. Bitsy's stove huffed. Bitsy's kettle whistled in a worried sort of way. "Watch this," said Monty, who had clearly been waiting all book for the moment. Pop — an identical jam stand sprouted beside Bitsy's. Pop — a third. Vera calmly sent each visitor to the shortest queue.
"I keep watchers on your stove," Monty explained. "When it works too hard for too long, I grow another stand from your blueprint. When the crowd goes home, I fold the spares away — never fewer stands than you asked for, never more than you can afford." Bitsy, for once, had absolutely nothing to worry about, which took some getting used to.
What's really going on
Autoscaling
An AutoScale group ties together an instance profile (template + compute offering), a load balancer rule, and min/max member counts. Counters (CPU, memory, and VR-collected network metrics) feed conditions ("CPU > 80%"), and scale-up / scale-down policies act when a condition holds for a set duration — provisioning a new instance from the profile or quietly destroying a spare one.
Since 4.18, autoscaling works out of the box with the CloudStack Virtual Router as the load balancer on KVM, VMware, and XenServer — no external appliance needed (NetScaler remains an option). Scaling activity lands in the event log, so the town book knows about every pop.
Chapter 17
The Stone Vault
After the storm, Bitsy asked the question that had been sitting quietly at the back of her mind. "Monty… photographs put my rooms back. But what if something happened to the barn itself? What if I needed a whole spare house, kept somewhere else entirely?"
Monty nodded like someone who had been hoping she'd ask. He showed her a stone vault, snug in a different corner of the forest, run by professional archivists with impressively serious keys. "Pick a plan from the menu," he said. "A full copy of your house every night, kept for a week — or whatever suits. If the worst happens, the archivists hand back your entire house. Or just the one cupboard you miss."
What's really going on
Backup & Recovery
The Backup and Recovery framework is a different tool than snapshots: it hands whole-instance backup to a dedicated provider — Veeam for VMware, the NAS backup plugin for KVM, or Dell EMC NetWorker — storing copies in the provider's own repository, outside CloudStack's primary and secondary storage.
Admins publish backup offerings (the menu of plans); users assign an instance to one, then take on-demand backups or set a schedule with retention. Restores can bring back the entire instance — even a deleted one — or recover a single volume and attach it to a running instance. Backup usage is metered, so Tally sees it too.
Chapter 18
Tune-Up Day
Some mornings, Bitsy would find a polite little sign on a neighboring treehouse: closed for repairs. Nobody panicked. Before a single plank was lifted, every family in that house had already glided along the zipline to the neighbors — then Monty got out his wrench. When a whole cluster needed its roofs re-shingled, he simply worked down the row, one empty house at a time.
Bitsy also finally saw the famous rulebook: a thousand careful dials, each with a label. How full a chest may get before new families go elsewhere. How many guests a house may promise before it's fibbing. "Most dials I never touch," Monty admitted. "But when the tree grows, it's rather nice that they exist."
What's really going on
Maintenance mode, global settings & tuning
Putting a host in maintenance mode live-migrates its instances to other hosts in the cluster before the admin patches, reboots, or reinstalls it; KVM rolling maintenance automates the whole cluster, host by host, with pre/post scripts. Zones, pods, and clusters can likewise be disabled to stop new placements.
Global settings are the dials — hundreds of them, many scoped per zone, cluster, account, storage pool, or domain (some need a management server restart). The ones every operator meets: over-provisioning factors (cpu.overprovisioning.factor, mem.overprovisioning.factor) that let a cluster promise more than it physically has, and capacity disable thresholds that stop new allocations before a cluster is truly full.
Chapter 19
Writing to Monty
One day Bitsy realized she'd never once had to find Monty — he simply appeared. "Ah," said Monty, appearing. "That's because you don't actually need me in person. There's a message window with pictures and buttons, for choosing houses the comfortable way. And there's the letter tube, for writing to me directly — every button in the window is secretly a letter anyway."
He taught her the two rules of the tube: seal every letter with your own wax seal, so he'd know it was really her and exactly what she was allowed to ask for; and for big requests, he'd send back a ticket right away and finish the work in his own time. He even gave her a tiny wooden monkey that answered in his voice from her own desk — and mentioned that some families kept clever robots who wrote hundreds of perfectly-sealed letters a day.
What's really going on
The UI, the API & CloudMonkey
The web UI (at http://<management-server>:8080/client) and the API are the same thing underneath: every UI action issues an API call. Requests are authenticated with each user's API key and secret key — the secret signs the request, the wax seal — and the user's role determines which of the hundreds of API commands they may call. Long-running commands are asynchronous: you get a job ID at once and poll for the result.
CloudMonkey (cmk) is the official CLI — the little wooden monkey on your desk — and the same API powers the Terraform provider, Ansible modules, and SDKs. Anything Monty does in this book, a script can ask for.
Chapter 20
Captain Kube Comes to Visit
One bright morning a whole family of Bitsy's cousins arrived at the roots — tiny apps who didn't want houses at all. They lived in snug little crates, traveled in pods, and brought their own captain: a solemn owl in a splendid hat, named Kube. "I arrange crates," said Captain Kube. "I am extremely good at it. But I do not build ships."
"Then we shall get along famously," said Monty. "Tell me how big a fleet you need, and I'll grow the ships from my blueprints, rope them together, patch them when they age, and grow more when your crates get crowded." And so they did: Monty tended the fleet, Kube arranged the crates, Vera showed visitors aboard, and the chests held the crates' toys. The cousins declared it the finest harbor in any forest.
What's really going on
The CloudStack Kubernetes Service (CKS)
CKS lets CloudStack create and manage Kubernetes clusters as first-class resources: once the admin enables the service and registers Kubernetes versions (shipped as ISOs), a user picks a version, a compute offering, and a size — and CloudStack deploys the control-plane and worker nodes as instances, wired up with kubeadm. Clusters can be scaled up or down, upgraded between versions, and given HA multi-master control planes; you download the kubeconfig and go.
The CloudStack cloud provider and CSI driver complete the picture: Kubernetes LoadBalancer services map to Virtual Router load balancing rules (Vera showing visitors aboard) and PersistentVolumeClaims become CloudStack volumes in primary storage (the chests). Monty tends ships; Kube arranges crates.
Chapter 21
Who Sleeps Where
"Monty," asked Bitsy one evening, "when a new family arrives, how do you decide which branch they sleep on?" Monty puffed up a little, because this was his favorite subject. "Rules! Some trees like new families spread far apart, so no single storm upsets too many. Some like them snug on one limb, to save candles. Houses that need a fireplace get branches with fireplaces — see the star stickers? And some friends ask never to share a branch, so if it cracks, at least one of them keeps baking."
And at night, while everyone slept, a small polite tidy-bot rolled along the branches, nudging houses from crowded limbs to quiet ones so that no branch ever groaned. Bitsy watched it work and found it strangely relaxing, like watching someone else fold laundry.
What's really going on
Deployment planners, tags, affinity & DRS
Deployment planners decide where a new instance lands: FirstFit packs hosts in order, UserDispersing spreads one account's instances across clusters/pods, UserConcentratedPod keeps them together; allocators make the matching host and storage-pool picks. Host and storage tags steer offerings to capable hardware (the star stickers), and affinity groups — notably host anti-affinity — keep chosen instances on different hosts so one failure can't take them all.
CloudStack DRS is the tidy-bot: per-cluster automated rebalancing with balanced or condensed presets, run on a schedule or on demand, live-migrating instances to even out (or consolidate) load.
Chapter 22
Keys and Badges
The Fern family was enormous — cousins beyond counting — and Monty's ledger got tired of new names. So the Ferns brought their own family register, kept by their own librarian, and Monty simply checked it whenever a Fern knocked. Other families showed a stamped badge from the town hall instead: one badge, good at every door in town, and Monty trusted the stamp.
The extra-careful added a secret knock that changed every single minute — a stranger who stole your key would still stand at the door, knocking wrongly, looking foolish. And for the houses themselves, Monty cut proper golden keys in matching pairs: one for your pocket, one built into the lock the day the house sprouted. "Doors," said Monty solemnly, "deserve at least as much cleverness as windows."
What's really going on
LDAP, single sign-on, 2FA & SSH keys
CloudStack can check credentials against an LDAP server (Active Directory or OpenLDAP — the family's own register), or delegate login entirely via SAML 2.0 or OAuth2 providers — the town-hall badge of single sign-on. Two-factor authentication adds the minute-by-minute knock (TOTP authenticator apps), and password recovery can be enabled for local accounts.
For the instances themselves, SSH key pairs are the golden keys: register or generate a pair, deploy an instance with it, and log in without passwords. Together with API key/secret signing (chapter 19) and roles, that's the whole keyring.
Chapter 23
Movable Gates and Far-Away Fields
Vera, it turned out, had cousins with unusual jobs. One kept movable gates: pick your gate up, wheel it to a different garden — even to a different tree entirely — and your visitors' letters still arrive, because the address travels with the gate. Another stood between whole forests, politely pointing each visitor to whichever tree was closest and least busy that day.
In the big shared meadows, where many families grazed side by side, low hedges kept each family's houses whispering only to each other, even on common ground. And for families with very particular taste in gatekeepers, Monty's blueprint book had a special chapter: bring the blueprint of your own favorite gatehouse, and he'd grow it right where a gate should stand.
What's really going on
Portable IPs, GSLB, private VLANs & VNF appliances
Portable IPs are elastic public IPs that can be transferred across networks, and even across zones and their guest networks stay reachable — the gate on wheels. (Elastic IPs in security-group zones similarly let you re-point a public IP between instances on demand.) Global Server Load Balancing (GSLB) spreads traffic across zones for multi-site services.
Private VLANs isolate tenants inside one shared network — hedges in the meadow — while VNF templates and appliances let you register third-party network appliances (firewalls, routers) as templates and deploy them as managed network functions. Remote access and site-to-site VPN round out Vera's extended family.
Appendix
Field Notes for Grown-Ups
Chapter-by-chapter map to the official docs
Where the real story lives
Every chapter distills a section of the Apache CloudStack 4.22 Usage Guide:
- Ch. 1, 3 — Concepts & terminology; Ch. 2 — Management Server architecture
- Ch. 4 — Templates & ISOs; Ch. 5 — Service offerings
- Ch. 6, 9 — Storage, volumes & snapshots; Ch. 7 — System VMs
- Ch. 8, 12, 23 — Networking & traffic; Ch. 16 — AutoScale
- Ch. 10 — Reliability & HA; Ch. 18, 21 — Hosts, Tuning & Deployment planners
- Ch. 11, 22 — Accounts, domains & projects; Ch. 13 — resource limits (accounts) & the Quota plugin
- Ch. 14 — Working with Usage; Ch. 15 — Events & alerts
- Ch. 17 — Backup & Recovery; Ch. 19 — UI & API; Ch. 20 — Kubernetes Service
Not in the story (operational corners worth knowing): object storage and shared filesystems; importing/unmanaging instances and VMware→KVM migration; GPU/vGPU instances; resource tags, comments & database configuration; troubleshooting; the extensions framework; and best practices.
And Bitsy lived scalably ever after.
She had a house that fit her exactly, a garden with a gatekeeper, photographs of everything she loved, and a monkey with a very good ledger watching over it all. Sometimes, on quiet evenings, she'd hear a new little app arrive at the roots of the tree and ask, in a very small voice, whether there might be a house to spare.
There always was. That was rather the point of the whole tree.