Troubleshooting

Start from what you are seeing. Almost every VServer problem is either "I cannot get in" or "the portal will not let me do the thing", and those are diagnosed completely differently.

Find your symptom

What you see	Where to go
Permission denied (publickey)	SSH refuses your key
SSH or ping times out with no answer	The server does not answer
The server sits in Provisioning, or shows Failed	The server never came up
This action needs the QEMU guest agent	Guest agent actions fail
Creating a snapshot fails with a generic error	A snapshot will not be created
disk can only grow (current 60G, target 40G)	A plan change is refused
The disk grew but df still shows the old size	The filesystem did not follow
The console will not connect	The console stays disconnected
Reverse DNS saves but does not change	Reverse DNS has no effect
The IPv6 address is not reachable	IPv6 does not work
Checkout refuses the order	The order will not go through
The invoice is higher than expected	The bill is higher than expected

SSH refuses your key

Permission denied (publickey).

The server is up and reachable, sshd answered, and it did not accept what you offered. Four causes, in order of how often they turn out to be it:

1. The server has no key at all. Overview shows a banner reading No access set up yet. That happens when the order or the reinstall was done without one. Recover with Settings → Install SSH key, see If you ordered without a key.
2. You are not connecting as root. The key is written to /root/.ssh/authorized_keys and nowhere else. There is no per-distribution debian or ubuntu user with your key on it.
3. Your client is offering a different key. Force the one you picked: ssh -i ~/.ssh/id_ed25519 root@<your-ip>.
4. A reinstall wiped it. The keys field in the reinstall dialog is a text box, not your stored keys, and leaving it empty rebuilds the server with no key.

The server does not answer

Nothing at all comes back: SSH hangs, ping gets no reply. Check the portal status on Overview first, because it splits the problem in two.

Status is Stopped. Press Start. If you did not stop it, look for the server down email, and check the Metrics tab for what the machine was doing before it went: a memory graph pinned at the top just before it stopped is the usual story.

Status is Active. The machine is running and the problem is inside it. Open the console, which does not go through the network stack, and look at what is actually on the screen:

• A login prompt means the machine is fine and something is blocking the network. A firewall rule is the first suspect. Check the server's own rules with nft list ruleset or ufw status, then systemctl status ssh, and check the Firewall rules card on the Network tab in the portal.
• A boot that stopped at an initramfs or emergency prompt means the disk or /etc/fstab. This is what the console exists for.
• A blank screen that reacts to Enter is a running machine with no getty on that console, which is normal on some images. Judge by whether the network came back instead.

The server never came up

Provisioning resolves on its own. A server that stays there long enough is marked Failed automatically and provisioning is retried up to three more times. If it still fails, billing for it is cancelled and the case is raised with us for a refund or a manual rebuild.

The portal does not show you the reason it failed. Contact support rather than ordering another one, because a failed order can be finished rather than paid for twice.

One exception worth knowing: during a reinstall or a plan change the status can show Failed for a while and then return to Active by itself. Let the operation finish before you act on it.

Guest agent actions fail

This action needs the QEMU guest agent running inside your server, but it
isn't responding.

Install SSH key and Reset root password both work through an agent inside the guest. It is not answering. Either the server is not running, it is still finishing its first boot, the agent was removed, or the image never had one.

If you can still get in, reinstall it:

apt install qemu-guest-agent && systemctl enable --now qemu-guest-agent

On Flatcar Container Linux there is no agent and these two actions will never work. If you are locked out of a Flatcar server, the only remaining route is a reinstall, which erases the disk.

A snapshot will not be created

The portal shows a generic failure with no detail. Count the snapshots on the Snapshots tab: the limit is 3 per server and a fourth is refused. Delete one you no longer need.

Entries labelled Automatic are safety snapshots from a plan change and do not count towards the 3, so if you see three of your own plus an automatic one, the three are the problem.

A plan change is refused

disk can only grow (current 60G, target 40G)

You asked for a smaller plan with Grow disk to new plan size still ticked. Disks never shrink. Untick it and the change goes through: the server moves to the new plan's CPU and memory and keeps the disk it has.

If you get resize already in progress instead, one is running. Wait for the server to leave Resizing.

The filesystem did not follow

The plan change succeeded and df -h / still reports the old size. The virtual disk grew; the partition table and the filesystem inside it did not.

lsblk

Grow the partition with growpart, then the filesystem with resize2fs (ext4) or xfs_growfs (XFS), using the device names lsblk printed. A reboot first is worth trying: most images do this by themselves on the next boot.

The console stays disconnected

The console can only attach while the server is Active or Stopped. In any other state, including during a reinstall or a plan change, there is nothing to attach to.

If the state is right and it still will not connect, click Connect again. Each attempt is authorised with a ticket that expires after 60 seconds, so a button you clicked and came back to later fails.

Reverse DNS has no effect

Saving the Reverse DNS field reports success, and the PTR record does not change. This is a known gap, not something you are doing wrong. See Reverse DNS and open a ticket with the record you need.

IPv6 does not work

Two causes cover nearly all of it.

You used the block instead of the address. The portal shows …:64:0/112, which is the range. The address configured on the server is the first one in it, …:64:1. See IPv6.

You reinstalled. A reinstall issues a new IPv6 block. The old address is gone and any AAAA record pointing at it is stale.

The order will not go through

insufficient IPv4 addresses available
insufficient node capacity (memory or disk) for the requested size

Stock is checked before your card is charged, and an order that could not be fulfilled is refused rather than accepted and failed later. A smaller plan may still be available; the shop marks plans that are out of stock as Sold out.

vserver capacity temporarily unavailable, please retry

Different case: stock could not be determined at that moment, so the order was refused on purpose. Try again.

The bill is higher than expected

Work through these in order:

1. A stopped server still bills. Stopping reserves the machine; it does not release it. Check whether something you thought was off is merely Stopped.
2. The cap is per server, not per account. Two servers on the same plan cost twice the plan.
3. A mid-month upgrade raises the cap for the whole month. The ceiling follows the plan the server is on now, see After a plan change.
4. The first month was prepaid. The month after it is the first one that looks like an hourly bill, which reads as an extra charge and is not.

Invoices → Estimated Costs shows the current month per server, so you can see which one is responsible before guessing.

What's next

• Ordering and first access for the recovery paths
• Billing for how the hourly cap works