Hi all,
One of our Dedicated Servers went down on the 25th of May.
After server failing to come up even in Rescue, OVH intervened physically on the server and, according to them, replaced the motherboard.
After the replacement the server never came up. We complained, they said it was user responsability.
This is the message (in Portuguese they sent)
Lamentamos a demora na resposta ao seu pedido, em primeiro lugar.
Contudo após análise por parte dos colegas, foi-nos dado que a configuração a efetuar é da sua responsabilidade, uma vez que se trata de um problema de software, no qual, o Mac Address não foi alterado em todos os ficheiros de configuração.
Estando o sistema operativo a tentar arrancar com o Mac Address antigo, daí não funcionar.Info:
- Antigo: 0C:C4:7A:47:XX:XX
- Novo: 0C:C4:7A:47:ZZ:ZZ"
Tendo o Promox base em Debian, será necessário verificar os ficheiros de configuração do SO, sendo possivel obter essa informação alterando o enp1s0 e vmbr0 pelas interfaces que aparecem no ifconfig.
Como tal, o estimado cliente terá de proceder com a devida alteração do Mac Address em todos os parâmetros de rede.
So basically they said its to me to “update” the mac-address somewhere on the host they also don’t mention where but send a link to this thread… from an external company, of other product, but anyway doing what it says here does… NOTHING
So we searched the entire system with egrep and all the possible ways of writing a mac address.
We found the file .ovhrc - edited there with the new mac address… system won’t bring the network stack up.
Debugging a little more we found that the cloud-init-local (pre-networking) service was always failed, so we digged a little more, and we noticed there was mentioned a “datasource” we traced to:
/var/lib/cloud/instance/datasource
The contents of this datasource are:
DataSourceConfigDrive: DataSourceConfigDrive [net,ver=2][source=/dev/sda5]
Well happens that this /dev/sda5 does not belong to us (nor our disk so to say) we have 2x2TB raid config, sda has 1 more part than sdb, and is this sda5.
To mount the sda5 I have to use -r -t iso9660
/dev/sda5 on /mnt type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048) [config-2]
Inside this partition there is a folder openstack/latest and on network_data.json the definition of a physical interface with the old mac-address.
I tried to remove the datasource file, and changing it, this file is created with every reboot.
We have this server down since the 25th of May. Today we are still waiting for someone at OVH to fix this. It’s 15 days of downtime and OVH doesn’t care.
They have supposedly escalated twice to admins, and return saying its our fault.
We have forwarded this situation to our lawyers and we’re purchasing servers with other companies and ditching OVH. We will sue the Portuguese branch of OVH as they open a local office everywhere, as they lack any knowledge and ability to provide any kind of support.
If you have a business and are looking for servers for your infrastructure, and if they are critical, STAY AWAY FROM OVH. Take a look at Hetzner for example, best thing is their prices already have tax, unlike here they’re all without tax. Their server auctions has amazing deals.
OVH is a company of poor professionals and poor processes.
A few months ago we had a very big issue with IPv6, debugged it, they would do a ping to the next hop and say everything was ok. It took them 2 months to solve the issue, and then OVH offered service time, but a bad IPv6 connectivity is totally different from a server that won’t come up by their responsability and totally refuse to do anything about it.
I am completely disgusted with OVH. One of the worst “companies” I’ve ever worked with.