Updated 29 October 2026 · Published by Zoorik
Amoeba is not showing my VM
Short answer. Amoeba lists only running VMs with at least one data disk, from the subscriptions Zoorik can read. A VM that can’t be onboarded is counted in one line under the list, with the reason. Once you onboard a VM, its used space and savings appear after its agent reports.
Read the line under the list
Look at: “Onboard VMs”, and the line under the list.
What it means: VMs that can’t be onboarded are counted in one line under the list, with the reason. For example, the VM is stopped, or it has only an OS disk.
What to do: Fix the reason shown, then open “Onboard VMs” again. The checks below explain what each requirement means.
Check the cloud connection
Look at: the connection’s state in the console.
What it means:
| State | What it means |
|---|---|
Verifying | Zoorik can’t read a subscription yet. The console says why: Zoorik’s app isn’t in your directory yet, the role isn’t assigned, or the directory wasn’t found. |
Connected | Zoorik reads your subscriptions through the role. |
Access lost | Zoorik lost read access to a subscription. Figures from Azure keep their last value, with its date, and onboarding waits. |
What to do:
- For “Verifying”: run the connect script the console shows in Azure Cloud Shell, with your own Azure sign-in. Then click “Verify”.
- The script adds Zoorik’s app to your directory, creates the role “Zoorik Storage Operator”, and assigns it on each subscription you name. You need permission to do all three.
- If the directory wasn’t found, check the directory (tenant) ID you entered in “Connect Azure”.
- For “Access lost”: check the role is still assigned to Zoorik’s app on that subscription. If it isn’t, run the connect script again. Zoorik checks access again regularly.
Check the VM’s subscription is included
Look at: the subscriptions you named when you ran the connect script.
What it means: The script assigns the role only on the subscriptions you name. Zoorik acts in your Azure only through that role.
What to do: Run the script for the VM’s subscription too. Then click “Verify” again: it picks up the subscriptions you added since.
Check the VM is running and has a data disk
Look at: the VM in Azure: whether it is running, and its disks.
What it means: Amoeba lists only running VMs with at least one data disk. It works on data disks and never touches the OS disk. The data on those disks must sit on mounted filesystems.
What to do: Start a stopped VM, then open “Onboard VMs” again. A VM with only an OS disk has nothing for Amoeba to move.
Give the list a moment
Look at: a VM you just created, started or changed.
What it means: The list comes from Azure Resource Graph, which can take a little while to catch up with changes.
What to do: Open “Onboard VMs” again a little later.
On AWS, check the instance
Look at: the EC2 instance, and how the account is connected.
What it means: Amoeba works on EC2 instances that are running and managed by AWS Systems Manager, with the SSM agent connected. Each must be a Nitro type that exposes EBS as NVMe, with at least one EBS data volume. The account connects with its AWS account ID and the IAM role ZoorikStorageOperator.
What to do: Connect the instance to Systems Manager, and check its type and volumes. If the account isn’t connected yet, run the script in AWS CloudShell that creates the role.
Check the agent has reported
Look at: the VM’s agent on Overview, and its figures.
What it means: Amoeba installs its agent on each VM you onboard, through Azure Run Command or AWS Systems Manager. The VM’s agent reads “Installing”, then “Connected” once its first report arrives. Until then, used space and savings read “Available once the agent reports”.
What to do: Wait for the first report. Each VM must be able to reach Zoorik, for the agent’s reports and commands, and the sites the agent downloads from.
If the install failed or the agent stopped
Look at: “Needs you” on Overview, and the VM’s Settings page.
What it means:
- The console says why an install failed: the script failed, Azure refused the run, or the install stalled.
- It also says when Zoorik can’t reach the subscription, or when the first report didn’t arrive in time.
- Amoeba tries again for as long as the VM stays onboarded.
- An agent that stops reporting reads “Disconnected”. Amoeba reinstalls it, but never during a move step or a pool operation.
- Until the agent reconnects, the pool stays mounted but can’t expand or shrink.
What to do: Click “Reinstall” in Settings → Agent. It starts a new install straight away, or when the current step of the move ends. It’s available while the VM is running.
Amoeba has not rightsized my disks yet
Short answer. Amoeba rightsizes a VM’s disks in two stages. First it moves the data onto one btrfs pool sized to your data, then it grows and shrinks the pool with your data. The checks below cover what holds each stage back, in order.
Check the agent is reporting
Look at: the VM’s status and its agent on Overview.
What it means: The move onto the pool starts by itself after the agent’s first report. “Ready for a pool” means the agent has reported. While the agent isn’t reporting, the pool can’t expand or shrink.
What to do: If the agent hasn’t reported, or reads “Disconnected”, see Amoeba is not showing my VM.
Check whether Amoeba declined the VM
Look at: the VM’s status, and the Disks page, which shows how many data-disk slots are in use.
What it means: During the move, the pool’s disks attach beside the old disks, so the VM needs a few free disk slots. A VM Amoeba declines, for example one with too few slots, shows why and stays on its own disks. Amoeba doesn’t move a VM that uses Azure Disk Encryption as it is.
What to do: Make room for the pool’s disks. For a VM that uses Azure Disk Encryption, email us.
Check whether the move paused
Look at: Pool → Migration, and “Needs you” on Overview.
What it means: The move pauses when a step can’t go on safely. For example, the VM can’t take a pool, a copy fails, or Amoeba can’t tell whether the switch worked. A disk error found after the switch also pauses it.
Pool → Migration shows where it paused and why.
What to do: Fix the reason shown. “Resume” appears when the move can run again: click it. If Amoeba can’t tell whether the switch worked, the move waits for you to click “Resume”.
Check the Linux requirements
Look at: on a Linux VM, its kernel, its packages and its services.
What it means:
- The kernel must be recent and support btrfs, built in or as a module. Amoeba loads the module if it isn’t loaded. If the kernel has no btrfs, the move pauses.
- The agent needs rsync, btrfs-progs and psmisc. The installer doesn’t add them.
- Every process that keeps a data mount open must run as a systemd service. Otherwise the switch can’t finish.
- The agent needs cgroup v2 to read disk load. Without it, the copy can’t slow down when your apps are busy.
- Amoeba checks the running kernel, never the OS name.
What to do: Install the missing packages, and run each service that uses a data mount under systemd. Then click “Resume” if the move paused.
Check the shrink setting
Look at: “When Zoorik shrinks” in Settings → Shrinking, and the Operations page.
What it means: In “Auto”, the default, each shrink starts by itself when the pool is quiet. In “Manual”, a shrink waits for you on Operations as “Waiting for you”, and Overview lists it under “Needs you”. Expands are automatic either way.
What to do: Click “Start shrink” on Operations. Or set “When Zoorik shrinks” to “Auto”, and click “Save”.
Give it time after the move
Look at: when the move finished, and how your data has changed since.
What it means: A shrink waits until the move is done and Amoeba has watched your data for long enough. It runs when your data goes down and stays down. Meanwhile, the pool still grows before it fills.
What to do: Nothing. Operations logs each expand and shrink, with its outcome and reason.
Read why a shrink can’t run
Look at: Operations. In “Manual”, a shrink that fails a check reads “Can’t shrink now”, with the reason.
What it means, and what to do:
| Reason | What to do |
|---|---|
No smaller layout would hold your data with room to grow. | Nothing. Amoeba shrinks when your data goes down and stays down. |
The pool is filling too fast to move the data safely. | Nothing. Amoeba grows the pool before it fills. |
The other disks couldn’t keep up with the VM’s disk load. | Nothing. Amoeba doesn’t shrink a pool when the disks that stay couldn’t serve your load. |
Amoeba is waiting for disk-load readings from the agent. | Check the agent is reporting. On Linux, the agent needs cgroup v2 to read disk load. |
The VM’s kernel is too old, or doesn’t support btrfs. | Use a recent kernel that supports btrfs. |
The pool reports disk errors. | Email us. Amoeba never shrinks a pool that reports disk errors. |
The VM size isn’t in Azure’s size list for its region yet. | Email us if it stays. |
Still stuck?
The Amoeba product guide and the Amoeba FAQ have the full detail.
Email founders@zoorik.com, or pick a time to talk (opens in a new tab). Tell us what “Onboard VMs”, the VM’s agent, Pool → Migration and Operations show. Remove tokens, keys and other secrets from anything you send.
Amoeba product guide: Before you startAmoeba product guide: Which VMs are listedAmoeba product guide: Connection statesAmoeba FAQ: What happens if the agent stops reporting?Amoeba product guide: Moving a VM onto its poolAmoeba product guide: What stops a shrinkAmoeba product guide: Stay in controlAmoeba FAQ: Which Linux distributions does Amoeba support?