Whole machines on the servers you already pay for.

A guest is not a container: its own kernel, its own disk, its own address. Vigia installs libvirt and KVM, then makes guests the way a person thinks about them — a machine from a cloud image in one form, or an ISO installed over a tunnel from your desk. Its disks live on the host; nothing Vigia does reaches inside the guest except the console.

The Virtualization tool in LockFlare Vigia: libvirt running, the guests with their state and resources, the storage pools with free space, the networks, and the bridge form
libvirt, the guests, the pools with their free space, the networks — and what the host has left to give.
/ CAN THIS BOX DO IT

The honest part first: can this box do it at all?

Most VPSs cannot run KVM — nested virtualization is off, or the CPU flag is not there. Vigia checks before it offers anything and says so plainly, because finding out after four hundred megabytes of packages is worse than being told no. Where KVM is available it names the extension it found; where it is not, it says what the box would need.

Beside it, one host that can: a guest from a cloud image with a port published, a guest installing from a disc through a tunnel from your desk, the pool its disks live in, and the two kinds of network.

A machine from a cloud image, in one form

Name it, pick the distribution, say how big. Vigia downloads that image once from the distribution itself and keeps it beside the pool, copies it for this guest, grows the copy to the size you asked, writes the cloud-init that configures it on first boot, and defines it. The next guest from the same image is seconds rather than minutes.

The form does the arithmetic you would otherwise do in your head: how many cores and how much memory this host actually has, how much is free right now, and what this image needs as a minimum. It asks for the login to create with sudo, an SSH key to install, and — this is the detail that saves an afternoon — a password for the serial console, because a cloud image ships without one and a console that shows a prompt nothing can answer is a machine you cannot get into. That password goes into the guest's cloud-init and the file is deleted the moment it has been handed over.

The job runs on the box on its own, so closing Vigia does not stop it, and it says so on the panel: keep working, it goes on.

From a disc, for everything with no cloud image

Windows, FreeBSD, an appliance, an old distribution — anything that arrives as an ISO. Download one into the pool from the form or drop it there with the Files tab. Naming the operating system lets libvirt pick the right devices for it — win11, win2k22, freebsd14, or blank and libvirt guesses from the disc; Windows 11 gets UEFI firmware with one tick.

Then the part that makes this usable on a server in a data centre: the guest's screen is VNC, bound to the host's own loopback and never to the outside. The Screen button opens a tunnel from your computer to it, so you click through the installer from your desk with nothing exposed on the internet. No VNC port open, no password to leak, no forgotten listener left behind afterwards.

/ ONE GUEST

The guest's own page

Start, shut down, reboot, start at boot, back up to a folder on the host, copy to a new guest with its own disks and its own MAC, read its definition as libvirt holds it. Then the things you actually come back for, each said in the words that matter rather than in libvirt's:

What it is given. A running guest can be given up to the ceiling it started with; raising the ceiling is always at its next boot. So the page shows both — in use, and at next boot — instead of pretending a change took effect when it did not.

Disks, as what the guest sees and what they actually take on the host, which are not the same number for a thin-provisioned image. Add one, grow one. Interfaces, with the note that an address appears once the guest has booted and taken its lease. Add a card, put it on another network.

Reachable from outside. A guest on NAT can get out; nothing gets in until a port of the host is pointed at it. Publishing one is three things at once, which is why it is a button and not a paragraph of documentation: Vigia pins the guest's address first so the forward cannot rot after a reboot, writes libvirt's hook so it survives one, and opens the firewall. Snapshots, taken off or running — running, its memory is written too, as much space as it has RAM — gone back to or deleted in one press, and the line that is simply true: a snapshot before an upgrade is the cheapest insurance there is.

Beside it, one guest's page, read the way the tool says it.

# web-1 · on srv-01 · running · starts at boot Start · Shut down · Reboot · Back up · Copy · Definition what it is given in use at next boot cores 2 4 memory 4 GB 8 GB # a running guest goes up to the ceiling it started with disks the guest sees on the host vda 40 GB 3.1 GB # thin interfaces default · NAT 192.168.122.41 # once booted, with its lease reachable from outside srv-01:8080 → web-1:80 address pinned · hook written · firewall open snapshots before-upgrade running · memory too · 4 GB

Pools, networks, and the one change that can cut the wire

Storage pools are where a guest's disk is made, so the page says the thing that actually bites: a pool that is full is a guest that cannot be created. Each with its path and its free space.

Networks in one sentence: NAT gives a guest a private address and a way out; a bridge puts it on the real network with an address of its own. A libvirt NAT network touches nothing on the host and can be made and stopped freely.

A bridge is different, and Vigia refuses to be casual about it. It rewrites the server's own networking — the interface's address moves to the bridge — and it is the one change on this screen that can cut the very connection Vigia is using. So the server arms a revert before anything is touched and puts everything back by itself if Vigia cannot prove it is still there afterwards. The form takes the address from the interface exactly as it is now, which is what keeps the session alive across the change, and says why leaving it on both is how a box ends up answering on neither. It also tells you which tool the box uses to configure networking, because that is the file it is about to rewrite.

/ THE LIMITS, SAID

What the tool will not pretend

It does not reach inside the guest.

Vigia manages the machine, not what runs in it. Its disks live on the host and nothing here reaches past the console — if you want the guest managed too, add it to the map as its own server.

Rates are real differences.

Network and disk numbers on a guest's page are honest differences of libvirt's running counters between two samples, not a gauge invented to look busy.

Nothing existing is touched.

Making a guest downloads an image, copies it, grows the copy and defines a machine. It does not alter the host's own storage, its services or its network — except the bridge, which says so twice.

Deleting keeps the disks.

Deleting a guest takes its definition away; its disks stay where they are unless you tick them too, with their names and what they weigh beside the box.

The console is a terminal.

The serial console of a guest opens as a real Vigia terminal tab, so a machine with no network is still reachable.

Removing it is a ceremony.

libvirt comes off the box through the same uninstall as everything else: Touch ID or Windows Hello, what actually goes, the phrase typed by hand, and the same check again.

Containers, on the same rail

For the workloads that do not need their own kernel: Docker with compose stacks, volumes backed up, and ufw made to govern its ports.

Containers, end to end