Note: Do not use OVHcloud for production services

note

Summary

Two failures of OVHcloud’s control plane took a single VPS offline within four days. Neither originated inside the guest. Neither could be fully resolved by the account holder.

In the first incident, OVHcloud’s automated backup issued a filesystem freeze through qemu-guest-agent and did not complete the corresponding thaw. All processes that performed disk I/O entered uninterruptible sleep. OVHcloud simultaneously locked the service in the state backuping. The Control Panel and API then refused reboot, stop, and start operations with Action not available while VPS is backuping.

The resolution was:

POST /vps/{serviceName}/abortSnapshot

The endpoint exists in the Canadian and European public API schemas. The Control Panel has no equivalent action.

In the second incident, a task of type rebootVm stalled in OVHcloud’s orchestrator. It locked the service with Action not available while there are running tasks on the VPS. The API provides only GET operations for VPS tasks. A customer can inspect the orphaned task but cannot cancel or delete it.

OVHcloud support did not supply the recovery method for the first incident. It has not resolved the second. One ticket was closed without a response. The replacement and related tickets remain open after multiple-day delays.

This article documents the symptoms, cause, recovery procedure, prevention measures, support response, and the reason I no longer consider OVHcloud VPS suitable for production services.

Environment

  • OVH VPS in BHS6, Beauharnois, Canada
  • OpenStack region os-bhs6
  • Ubuntu 26.04 LTS
  • Linux kernel 7.0.0-28-generic
  • qemu-guest-agent installed and running
  • Access through SSH, Tailscale, and the OVHcloud KVM console with noVNC

First incident: OVHcloud automated backup froze the VPS

SSH and all application services stopped responding. The KVM console remained available and displayed repeated kernel messages:

INFO: task systemd-journal:816 blocked for more than 122 seconds.
      Not tainted 7.0.0-28-generic #28-Ubuntu
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
INFO: task tailscaled:1299 blocked for more than 122 seconds.
INFO: task rs:main Q:Reg:1493 blocked for more than 122 seconds.

Application threads appeared in the same list. Uptime at the time of capture was 34,038 seconds.

These tasks were in uninterruptible sleep, which Linux reports as task state D. A task enters this state while it waits for a kernel operation that cannot be interrupted. Storage I/O is a common cause. Signals do not help because the task cannot process them until the kernel operation returns.

systemd-journald and rsyslog appeared early because they write to disk continuously. tailscaled and application threads followed when they attempted their next filesystem operation. The kernel continued to run and printed another warning after each hung-task interval. Disk-dependent userspace could not make progress.

The console showed a login prompt but did not accept a login. This was expected. login must read PAM modules, account configuration, and /etc/shadow from the frozen filesystem. A working virtual console does not bypass storage.

Why this pointed to an OVHcloud backup freeze

The console output alone could also indicate failed block storage or severe swap thrashing. The provider state identified the other half of the failure.

OVHcloud reported the VPS state as:

backuping

Every recovery action returned:

{
  "class": "Client::Forbidden",
  "message": "Action not available while VPS is backuping"
}

OVHcloud’s automated backup documentation states that each VPS includes a daily Standard automated backup. It also states that OVHcloud uses the QEMU Guest Agent to prepare the guest filesystem for a live snapshot.

The relevant sequence is:

guest-fsfreeze-freeze
snapshot
guest-fsfreeze-thaw

The QEMU Guest Agent protocol defines guest-fsfreeze-freeze as an operation that syncs and freezes freezable local filesystems. A later guest-fsfreeze-thaw operation must unfreeze them.

The observed state matches a freeze that completed without a successful thaw. From inside the guest, this resembles a failed block device. Writes block. Reads that miss the page cache block. The hung-task detector reports each affected process after its timeout.

Filesystem quiescing is a normal snapshot technique. It produces a filesystem-consistent image instead of an image taken while writes remain in progress. The unacceptable part is the missing recovery boundary. A failed snapshot must not leave the guest frozen and the service lock active across two days.

Recovery: call abortSnapshot

The working recovery action is:

POST /vps/{serviceName}/abortSnapshot

This cancels the snapshot or automated backup operation. It releases the backuping lock and permits a reboot.

The endpoint is defined as a production operation in the OVHcloud public API schema:

The Control Panel does not expose an equivalent button.

First, list the VPS services associated with the account:

GET /vps

Inspect the service and its tasks:

GET /vps/{serviceName}
GET /vps/{serviceName}/tasks

If the service state is backuping, call:

POST /vps/{serviceName}/abortSnapshot

Poll the service until its state is no longer backuping:

GET /vps/{serviceName}

Then reboot it:

POST /vps/{serviceName}/reboot

The abortSnapshot endpoint recovered this VPS. OVHcloud support did not provide it. I found it through another customer’s report of the same failure.

An r/ovh report of repeated automated-backup freezes describes equivalent production outages and the same abortSnapshot recovery. That report describes incidents beginning in April 2026 and a major incident on 19 June 2026.

Customers should not have to search Reddit for the control required to recover from a provider-created lock.

Use the official Python client

If the API console does not authenticate, use the official Python client:

import ovh

client = ovh.Client(
    endpoint="ovh-ca",  # Use "ovh-eu" for a European account.
    application_key=AK,
    application_secret=AS,
    consumer_key=CK,
)

print(client.post("/vps/vps-xxxxxxxx.vps.ovh.ca/abortSnapshot"))

Create application credentials at ca.api.ovh.com/createApp for a Canadian account or eu.api.ovh.com/createApp for a European account. The account region determines the API endpoint. The physical VPS datacentre does not.

A consumer key can be requested with client.new_consumer_key_request() and scoped recursively to /vps.

I published an OVH VPS recovery script that performs credential setup, identifies blocking tasks, calls abortSnapshot, waits for the lock to clear, reboots the VPS, and probes SSH. It can also report task timestamps without changing the service.

Use:

python3 ovh_reboot.py --status
python3 ovh_reboot.py --abort-snapshot

The script cannot clear an orphaned rebootVm task. OVHcloud does not provide a customer-accessible operation for that task type.

Why the other recovery methods failed

Control Panel reboot and hard reboot

The Control Panel and API refused all power operations while the automated backup held the service lock. A provider-side hard reset is not independent of the OVHcloud orchestrator. It goes through the same state checks as the other actions.

KVM login

The KVM console gives direct keyboard and display access to the virtual machine. It does not bypass the guest filesystem. Authentication cannot complete when PAM and account files cannot be read.

Ctrl+Alt+Del

The noVNC Ctrl+Alt+Del action did not recover the machine. It requests an orderly shutdown. That path requires functioning userspace and filesystem access.

Linux Magic SysRq

Magic SysRq can work because it operates in the kernel. The emergency sequence is:

Alt+SysRq+s
Alt+SysRq+u
Alt+SysRq+b

The first operation requests a sync. The second remounts filesystems read-only. The third performs an immediate reboot. If the filesystem is frozen, sync and remount can also stall. Alt+SysRq+b does not wait for storage, but it loses unflushed writes.

Ubuntu commonly ships with kernel.sysrq = 176, which permits sync, remount read-only, and reboot. The practical problem is noVNC input. SysRq usually requires a Print Screen keycode. macOS does not provide a normal Print Screen key, so the browser has nothing useful to forward. An external PC keyboard, a Karabiner-Elements mapping to print_screen, or a Linux or Windows client can provide the keycode.

A production hosting control plane should provide a forced reset that does not depend on a browser keyboard workaround.

Prevention

Apply these measures in order.

1. Block the filesystem-freeze RPCs

Current QEMU releases support block-rpcs, which disables selected guest-agent operations. QEMU documents the option and configuration key.

Create or edit /etc/qemu/qemu-ga.conf:

[general]
block-rpcs=guest-fsfreeze-freeze,guest-fsfreeze-freeze-list

Restart the guest agent and inspect its effective configuration:

sudo systemctl restart qemu-guest-agent
qemu-ga --dump-conf | grep -i block-rpcs

Block only the two freeze operations. Keep guest-fsfreeze-thaw and guest-fsfreeze-status available. If another path freezes the filesystem, the host must retain the ability to inspect and thaw it.

Check the installed unit:

systemctl cat qemu-guest-agent

QEMU reads its configuration file before its command-line arguments. QEMU documents that the last scalar option wins and RPC lists accumulate. If the unit supplies its own RPC options through $DAEMON_ARGS, inspect qemu-ga --dump-conf after restart. If the expected block list is absent, set the command-line option in /etc/default/qemu-guest-agent:

DAEMON_ARGS="--block-rpcs=guest-fsfreeze-freeze,guest-fsfreeze-freeze-list"

Use qemu-ga --version and qemu-ga --help to confirm the option supported by the installed release. Older documentation can refer to the former --blacklist name. Current QEMU uses --block-rpcs.

OVHcloud does not document the exact behavior of its backup worker when the freeze call is refused. The likely result is a crash-consistent snapshot or a failed snapshot operation. Do not assume the provider backup remains usable. Watch the next backup window and verify the result. Keep an independent backup outside the OVHcloud VPS control plane.

The blunt alternative is to disable the guest agent:

sudo systemctl disable --now qemu-guest-agent
sudo systemctl mask qemu-guest-agent

OVHcloud’s US automated-backup guide recommends disabling or removing QEMU packages as a troubleshooting step when automated backups cause downtime. Blocking only the freeze RPCs preserves the other guest-agent functions.

2. Release the automated backup option

OVHcloud documents the included Standard automated backup as automatic. Its customer documentation does not provide a normal disable control.

The current API schema defines vps.BackupStateEnum with enabled and disabled values. It also exposes a generic option-release endpoint. automatedBackup is a valid value of vps.VpsOptionEnum:

DELETE /vps/{serviceName}/option/automatedBackup?deleteNow=true

The endpoint is marked deprecated. Its schema lists a deletion date of 1 June 2024, but it remains present in the current Canadian and European schemas in August 2026. Whether it accepts the included Standard option depends on the account and service contract.

The recovery script supports this request:

python3 ovh_reboot.py --backup-status
python3 ovh_reboot.py --disable-backup

Do not treat a successful API response as proof that future jobs have stopped. Read the backup state again and monitor the next scheduled window.

3. Convert a filesystem hang into a reboot

After the freeze RPCs are blocked, configure Linux to panic when a task remains hung and reboot after the panic:

# /etc/sysctl.d/99-hang.conf
kernel.hung_task_panic = 1
kernel.hung_task_timeout_secs = 120
kernel.panic = 30
kernel.panic_on_oops = 1

Apply the configuration:

sudo sysctl --system

Do this after blocking the freeze calls. If snapshots can still freeze the filesystem, a backup that holds the freeze longer than 120 seconds can intentionally panic the VPS.

This is a safety net. It does not correct OVHcloud’s control plane. A reboot can still be blocked or followed by another provider-side task failure.

Timeline

1 August 2026, 12:53. The VPS became unresponsive. The console showed repeated hung-task messages. OVHcloud reported the service state as backuping. The Control Panel and API refused all recovery operations.

1 August 2026. The VPS was recovered with POST /vps/{serviceName}/abortSnapshot. The endpoint came from a public report of an equivalent June 2026 incident, not from OVHcloud support.

1 August 2026. A support ticket was opened with task types, timestamps, OVH-Query-ID values for refused calls, console output, and six direct questions. These included why a failed backup blocks reboot, stop, and start without a customer-accessible cancellation control.

2 August 2026. OVHcloud closed the ticket without a response.

3 August 2026. The VPS became unresponsive again.

4 August 2026. The second incident remained active after 18 hours. OVHcloud had not provided a response.

Second incident: an orphaned rebootVm task

The second incident had a different lock and no customer-side recovery.

OVHcloud reported the service state as:

rebooting

The Control Panel returned:

An error has occurred requesting to reboot.
Action not available while there are running tasks on the VPS

GET /vps/{serviceName}/tasks showed one pending task:

id          85863049
type        rebootVm
state       todo
progress    50%
startDate   null
lastUpdate  null

A queued task that reports 50 percent progress while it has no start date and no last-update timestamp is not providing credible evidence of execution. Its record existed in the orchestrator and held a lock on the service.

A task of type rescheduleAutoBackup also appeared on the service. That operation changes the scheduled time of the automated backup. The account holder did not request it.

The public schema exposes only these task operations:

PathMethods
/vps/{serviceName}/tasksGET
/vps/{serviceName}/tasks/{id}GET

There is no public cancel, delete, retry, or abort operation for a generic VPS task. abortSnapshot applies to snapshot and automated-backup operations. It cannot clear an orphaned task of type rebootVm.

The customer can see the lock but cannot release it. OVHcloud must repair the orchestrator state.

OVHcloud support was part of both outages

Support latency becomes infrastructure latency when the customer has no recovery control.

Only OVHcloud could answer whether its backup worker sent guest-fsfreeze-thaw, why the backup lock did not expire, why an unstarted rebootVm task reported 50 percent progress, or who submitted rescheduleAutoBackup. Only OVHcloud could remove the second orphaned task.

The support path did not provide those answers. The first ticket was closed without a response. The second incident remained open after 18 hours. Related tickets remained open across multiple days.

A production hosting provider must provide a fast escalation path for control-plane locks. OVHcloud instead made its support queue part of the recovery time.

The required response is specific:

  • Give the exact start, update, completion, and cancellation timestamps for each task.
  • Confirm whether guest-fsfreeze-thaw was sent and what response the host received.
  • Explain why the backup task and service lock did not expire.
  • Explain why rebootVm had no start date or last update while it reported 50 percent progress.
  • Identify the origin of the unrequested rescheduleAutoBackup task.
  • Add forced cancellation controls to the Control Panel and public API.
  • State whether Standard automated backup can be disabled.
  • Confirm whether blocking guest-fsfreeze-freeze is supported.
  • Publish a root cause analysis.
  • Apply the applicable service credit.

Closing a ticket when the VPS returns is not a root cause analysis. It leaves the same provider operation ready to cause the same outage again.

Assessment

A hosting provider suitable for production must meet two minimum conditions. The customer must be able to force a machine into a known state without waiting for provider support. Provider maintenance must also have bounded failure and recovery behavior.

OVHcloud VPS failed both conditions twice in four days.

The first failure combined a frozen guest filesystem with a provider-side backuping lock. The Control Panel and API refused every normal recovery action. The escape hatch existed as a specific API endpoint but was absent from the Control Panel and was not supplied by support.

The second failure was more severe from an operations perspective. An orphaned rebootVm record held the service lock. The public task API was read-only. No customer action could remove it.

These controls are not independent. Reboot, hard reboot, stop, and start all depend on OVHcloud’s orchestrator accepting a new task. When the orchestrator state is wrong, all recovery controls fail together. The KVM console cannot replace an out-of-band reset when storage access or userspace is unavailable.

The automated backup also runs inside the same failure domain as the production VPS control plane. It can initiate filesystem quiescing, retain the service lock, and then prevent recovery. A backup should reduce risk. This design can create the outage and block its repair.

The guest kernel behaved consistently with a frozen filesystem. In the second incident, the visible evidence identified an orchestrator record with no start or update timestamps. The available evidence points to management-layer failures, which are the failures a customer cannot inspect, patch, or route around.

Low cost does not compensate for unbounded recovery time. Capacity, network performance, and nominal uptime are not sufficient when a routine provider operation can stop a production service and deny the account holder a reset.

Systems where downtime is acceptable and recovery time is unbounded can run on this platform. Production services should not.

Frequently asked questions

What does Action not available while VPS is backuping mean?

A snapshot or automated-backup operation holds a lock on the service. OVHcloud refuses other actions until the operation completes. If it does not complete, call:

POST /vps/{serviceName}/abortSnapshot

What does Action not available while there are running tasks on the VPS mean?

A queued task holds the service lock. Retrieve the task list:

GET /vps/{serviceName}/tasks

Inspect each pending task with:

GET /vps/{serviceName}/tasks/{id}

abortSnapshot can clear a stuck snapshot or automated backup. The public API does not provide a cancellation operation for other VPS task types.

The console reports blocked for more than 122 seconds. Is the disk failing?

Not necessarily. The message means that tasks remained in uninterruptible sleep beyond the hung-task timeout. Failed block storage can cause it. A filesystem frozen through qemu-guest-agent can produce the same symptoms.

Check whether OVHcloud reports the service state as backuping and whether an automated-backup task is active before you conclude that the disk failed.

Can the included OVHcloud automated backup be disabled?

OVHcloud’s customer documentation does not provide a normal disable control for the included Standard backup. The API defines a disabled state and still exposes the deprecated option-release endpoint:

DELETE /vps/{serviceName}/option/automatedBackup?deleteNow=true

Whether OVHcloud accepts it depends on the account and service. Blocking the freeze RPCs inside the guest prevents this specific filesystem-freeze path even if the backup option remains attached.

Can a customer cancel a stuck OVHcloud VPS task?

Only snapshot and automated-backup operations have the specific abortSnapshot action. Generic task endpoints are read-only. A customer cannot cancel an orphaned rebootVm task through the public API.

Does blocking guest-fsfreeze-freeze break the provider backup?

OVHcloud does not document the fallback behavior. The snapshot may continue without quiescing and be crash-consistent, or the operation may fail. Verify the next backup and maintain an independent backup that you have tested.

Status, recovery script, and reports

The second incident remained unresolved at the time of writing. The orphaned rebootVm task had held the service lock for 18 hours.

The OVH VPS recovery script performs credential setup, reports blocking task details and timestamps, calls abortSnapshot, waits for the backup lock to clear, reboots the service, and probes SSH. It cannot resolve an orphaned rebootVm task because the public API provides no cancellation operation.

For corrections or related incident reports, contact me.