📚 Browse docs

Operations

Operations is the single place to answer “what is Asternodis doing right now, and what did it do earlier?” Every tracked operation reports here: failovers, failbacks and aborted failovers; DR tests and stopping them; the prepare, commit and roll-back steps of a planned move; taking a recovery point and repair-testing one; restores from a backup or in place; deleting recovery artifacts from Shadows; stopping protection of a guest; the guest fixes (Fix agent, Install guest agent, Fix home addressing, Fix disk cache, Add a graphical console); the automatic recovery of a stranded failover; and recovery-plan runs.

A Re-seed replica is not an operation in this list: it is recorded in the audit log, and you follow the full copy it starts on the guest’s Replication row (Re-seed pending while the copy waits to start, and the seed progress bar while it runs).

Active & recent

The live feed. It merges in-flight guest operations and recovery-plan runs from both sides of the pair, so an operation you started from the primary but which actually executes on the recovery side still appears here. You don’t have to log into the other site to watch your own failover.

Each row deep-links to that operation’s own progress page, which streams the steps as they happen: bytes moved, timings, warnings, and the exact error if a step fails.

Any DR test that hasn’t been stopped is surfaced here too, with its test copy’s VMID, the site it’s on, and View results and Stop DR test buttons, so a forgotten test bubble is never invisible.

Outcomes

A completed run ends in one of five outcomes, shown as the row’s status:

  • done: a clean success.
  • error: the run failed, and the row carries the reason.
  • partial (amber): a run that did what it could but left something outstanding, such as an unprotect whose recovery-side release didn’t go through (the site refused it, or couldn’t be reached), or a failback whose DR copy could not be folded back into the shadow (the next cycle re-seeds it in full instead). Partial names the specific leftover, and survives a controller restart.
  • cancelled: you stopped the run on purpose. It is shown as cancelled, not as an error.
  • interrupted: the controller restarted while the operation was running, or the operation stopped reporting progress and was closed out so it no longer blocks the guest. Check the guest’s actual state before retrying. (A recovery-plan run cut short this way reads error.)

Every completed run, successes included, shows its closing message. An aborted failover, for example, is a clean success whose DR copy is deliberately left in place for you to inspect (see Shadows); the list says so.

Earlier operations

The durable journal. Where the live feed is in-memory, this is persisted, so it survives a controller restart: the history doesn’t vanish because you rebooted the box. It merges the local and peer journals and tags each row with the site that actually executed it, so the page reads the same from either end of a pair.

It’s paged, because a busy estate produces a lot of operations and an unbounded list stops being scannable.

Why operations are durable

A DR operation is exactly the kind of work you cannot afford to lose track of halfway through. Asternodis writes each one to a journal as it goes, so:

  • closing the tab doesn’t cancel or hide anything: the work runs on the server
  • a controller restart mid-failover leaves a record you can pick up
  • “did that failback ever finish?” has an answer weeks later