What do I do if Support will not respond to my Ticket when the VPS has been inaccessible for over 4 days. I have tried following their template answer and it does not work. The VPS has a kernel panic in the KVM to do with inaccessible boot disk. I have sent Support evidence three days ago and they have ignored me. Fortunately this is only a test server but at this moment I would certainly not consider spending more money with OVH to get more VPSs.
Hello @webcliq
Call OVH support at +33 9 72 10 10 07.
Preferably between 8 a.m. and 9 a.m. in the morning, or around 3 p.m. there is less waiting.
Or already now on Twitter @ovh_support_fr or #OVHcloudsupport
Hi,
Can you give more precise details? Specifically the copy of the kernel panic error.
Hello @webcliq
When the VPS doesn’t boot because of a disk or kernel problem, rescue mode is your best ally. It’s a tool provided by OVHcloud to start the server with a temporary operating system and gain access to the files.
https://support.us.ovhcloud.com/hc/en-us/articles/115001754490-How-to-activate-and-use-rescue-mode
From the client area, reboot the VPS in rescue mode. Once inside, you can mount the disk that won’t boot; it usually shows up as an additional disk.
Let us know, best regards.
Sergio Turpín
It’s true that a four‑day wait is long. OVHcloud has different support levels. With Standard support (the default one), responses to non‑critical tickets can take hours or even days, because the team is available Monday‑to‑Friday during business hours.
In addition, technical support usually focuses first on hardware issues that they can resolve automatically, and software or operating‑system configuration problems, such as a kernel panic, are typically the customer’s responsibility.
Take a look at this 
Once everything is resolved, and before putting your server into production, check out the different support levels the company offers:
https://www.ovhcloud.com/es-es/support-levels/
Hope I helped you,
Sergio Turpín
You need to restart the VPS in rescue mode and check the system configuration:
https://docs.libremaster.com/infogerance/cloud/ovh-vps-boot-rescue-mode/
Then, inside the chroot, verify or update the kernel, check GRUB and the access to the correct boot partition,…
I received an email to say that the Kernel Panic fault on our VPS servers was nothing to do with OVH and we had to fix the problems ourselves.
This was my response:
Dear Support,
The contents of last email is noted. To summarise, you are saying that upon reflection, you have decided that the problem that I have reported is not your responsibility to fix or get involved with. I have looked at the summary of your SLA and indeed in an analysis of it, created by Cambridge University, they state the following:
For an OpenStack Virtual Private Server (VPS), responsibility is split using a Shared Responsibility Model. The provider owns the underlying physical infrastructure, while the user has total administrative control and responsibility for everything inside the VPS itself.
Provider Responsibilities
The cloud service provider manages everything required to keep the hardware running. This includes:
- Physical Infrastructure: Security of the data centres, hardware failures, power, and cooling.
- Hypervisor & Virtualization: Managing the core OpenStack components (like Nova) and ensuring the hypervisors are updated and secure.
- Basic Network: Provisioning the physical network, switches, and underlying IP fabric.
User Responsibilities
Because OpenStack gives you root/administrative control over your VPS, you are responsible for the entire software stack that lives on the virtual machine. This includes:
- Operating System: Installing, configuring, and updating the OS (e.g., Linux or Windows patches).
- Security & Firewalls: Managing your own software firewalls, security groups, and encryption.
- Applications & Data: Securing, updating, and backing up the applications and data hosted on the VPS.
For that reason, your Management has decided, in the midst of the problems that you must be suffering, that the easiest way to deal with these Tickets, is renege on all responsibility.
There are two problems with that.
Firstly, you caused it! By doing a Patch upgrade. If it was likely to have such an effect, you should have:
- Tested it on other equipment before using it on production servers
- Given all of customers advance warning of such a critical move, so that we could take necessary backups and precautions in advance.
- Generally been significantly more careful and had sufficient staff and resources to hand to deal with any problems
Secondly, the base disk of any Virtual Private Server is the responsibility of the Provider. If on booting any Virtual Server, it cannot access its /root partition. The service for which we have contracted and paid is not being provided.
I accept that a "kernel panic" is an Operating System function as defined under "User Responsibilities" above but if the kernel panic is caused by the inability of the Hypervisor to provide the Virtual Instance with a disk from which to Boot, because the Boot sectors have been deleted by the Crash of the Operating System when it was forced to shutdown unexpectedly or forcefully terminated by your need to do a Patch Upgrade, it makes it your responsibility.
This afternoon I have liaised with my Colleague who has the control and login details for the other VPS that I mentioned in my Ticket messages, which has the IP Address 51.254.142.227. We accessed the KVM for this VPS instance and it is displaying exactly the same error as is my VPS.
This cannot be and is not a coincidence. Your Patch upgrade caused this and most likely the pressure on your Support Staff is currently being caused, by trying to deal with this problem on countless VPSs that you have where you provide a higher level of support contract than we have.
By your negligent actions, you have damaged our Virtual Private Servers. You are, in practice, in breach of your contracts with my colleague and I.
My VPS was a test instance to see how reliable it was and your service was.
My colleagues VPS was a production instance and contains the management database for a business community improvement scheme in our Town.
My colleague (working with our Team) sells IT and web services to that business community.
You have damaged your reputation with them, my colleague and I.
You have marked my Ticket resolved when it is not resolved.
We have an expression in English that you have done a "slopey shoulders" on this problem.
I give you one last chance to work with me to solve the problems on my VPS so I can replicate that solution on the other VPS, mentioned, for which I am also responsible.
What I now need to know, is anyone else suffering from this problem?
Send the screenshot of the kernel panic here.
Also give the OS version, whether it was up to date before the kernel panic, and how long it had not been rebooted.