Do not use OVHcloud for production services - LagomorphSkip to content<br>Note: Do not use OVHcloud for production services<br>Aug 4, 2026 @ 13:52:00

note<br>Alex S.

Summary<br>Two failures of OVHcloud&rsquo;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.<br>In the first incident, OVHcloud&rsquo;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.<br>The resolution was:<br>POST /vps/{serviceName}/abortSnapshot

The endpoint exists in the Canadian and European public API schemas. The Control Panel has no equivalent action.<br>In the second incident, a task of type rebootVm stalled in OVHcloud&rsquo;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.<br>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.<br>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.<br>Environment<br>OVH VPS in BHS6, Beauharnois, Canada<br>OpenStack region os-bhs6<br>Ubuntu 26.04 LTS<br>Linux kernel 7.0.0-28-generic<br>qemu-guest-agent installed and running<br>Access through SSH, Tailscale, and the OVHcloud KVM console with noVNC<br>First incident: OVHcloud automated backup froze the VPS<br>SSH and all application services stopped responding. The KVM console remained available and displayed repeated kernel messages:<br>INFO: task systemd-journal:816 blocked for more than 122 seconds.<br>Not tainted 7.0.0-28-generic #28-Ubuntu<br>"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br>INFO: task tailscaled:1299 blocked for more than 122 seconds.<br>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.<br>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.<br>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.<br>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.<br>Why this pointed to an OVHcloud backup freeze<br>The console output alone could also indicate failed block storage or severe swap thrashing. The provider state identified the other half of the failure.<br>OVHcloud reported the VPS state as:<br>backuping

Every recovery action returned:<br>"class": "Client::Forbidden",<br>"message": "Action not available while VPS is backuping"

OVHcloud&rsquo;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.<br>The relevant sequence is:<br>guest-fsfreeze-freeze<br>snapshot<br>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.<br>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.<br>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.<br>Recovery: call abortSnapshot<br>The working recovery action is:<br>POST /vps/{serviceName}/abortSnapshot

This cancels the snapshot or automated backup operation. It releases the backuping lock and permits a reboot.<br>The endpoint is defined as a production operation in the...