Upgrade a plan with as little downtime as possible

What can be done hot

• Cores: added live, provided the target size fits on the current host. It usually does.
• Memory: added live, same condition.
• Extra NVMe: added live, always.
• Root disk: grown live, with the filesystem extended underneath you.

What cannot: shrinking anything, and moving between families. Ryzen to EPYC is a different machine, so it is a move rather than an upgrade — the same procedure as changing site, minus the change of city.

Doing it

curl -s -X POST https://paragonvps.com/api/v1/instances/<instance-id>/resize -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"plan":"r-12","mode":"hot"}'

"mode":"hot" refuses the change rather than rebooting when it cannot be done live. Use it. The permissive default is how instances end up restarting at eleven on a Friday.

Making the guest notice

New cores arrive offline on some kernels:

lscpu | head
grep . /sys/devices/system/cpu/cpu*/online
echo 1 > /sys/devices/system/cpu/cpu8/online

Make that automatic so the next upgrade needs nothing from you:

cat > /etc/udev/rules.d/80-cpu-hotplug.rules <<EOF
SUBSYSTEM=="cpu", ACTION=="add", TEST=="online", ATTR{online}=="0", ATTR{online}="1"
EOF
udevadm control --reload

Memory blocks tell the same story:

free -h
echo online > /sys/devices/system/memory/auto_online_blocks

That setting does not survive a reboot. Add memhp_default_state=online to the kernel command line to keep it.

Growing the root filesystem

The block device gets larger. The partition and the filesystem do not follow on their own:

lsblk
growpart /dev/vda 1
resize2fs /dev/vda1

On XFS the final step is xfs_growfs /. Both images already carry growpart. The gap between growing the partition and resizing the filesystem is the one second where a power cut would be inconvenient.

Applications do not notice either

Most daemons read the CPU count once, at startup. A web server that chose four workers on a four-core instance is still running four workers on your new twelve-core one. Restart the services, or set worker counts explicitly rather than leaving them on auto:

nproc
systemctl restart nginx

Anything holding a memory pool needs the same attention. Doubling the RAM does nothing at all for a database still instructed to use four gigabytes of buffer.

What it costs

Pro-rated to the second. The difference between old plan and new, for the remainder of the cycle, is taken from your account balance if there is one and invoiced if there is not. Downgrades credit the balance rather than paying out to a chain, because returning a small amount of coin costs more in network fees than the credit is worth.

The renewal date does not move. An upgrade on the twentieth renews on the twentieth, the same as it did before. Current rates are on the pricing page.

When it fails

If the host cannot take the new size, the API says so and nothing changes. From there it becomes a move: same disk, different machine, a few minutes of downtime, and the plan change applied at the far end. We do that part; you get an email with the window.