We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

RPS - I might find an answer...


mmgRay
28-09-2009, 18:49
My details are FIXED, I have also sent out an email to your support address (customersupport@ovh.co.uk) that basically contains the same information that i posted in this topic.

marks
28-09-2009, 17:08
So, have you checked the firewall? make sure that it complies with the rules specified in the guide so that our monitoring system and the firewall don't have conflict.

Otherwise, if that's not the case for your case, you'll have to give us the server name. If you want, directly to the support email address.

mmgRay
28-09-2009, 15:29
Hello Marks,

Yes, I do have connection problems with SSH, all policies are set to accept so that can't be the problem. I have had the same problem last month and after contacting technical support it basically came to the point where they just didn't know what the problem was, in the end it got magically fixed.. Now I have seem to lost all hope..

marks
28-09-2009, 15:16
Do you also have connection problems to access the SSH port?

If you're running a firewall as the other customer, it's worth checking whether the configuration so that our monitoring system is allowed to ping the server:

http://help.ovh.co.uk/firewall

Let me know

mmgRay
28-09-2009, 13:43
I seem to be having the same problems and the same errors in log files, we have had outage twice in 3 months, all not our fault yet OVH tells us to fix it ourselfs, heres the log output;

Sep 28 02:35:45 kernel: connection1:0: detected conn error (1011)
Sep 28 02:35:45 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Sep 28 03:13:28 kernel: session1: target reset succeeded
Sep 28 03:13:29 iscsid: connect failed (111)
Sep 28 03:14:26 last message repeated 2 times
Sep 28 03:14:42 logrotate: ALERT exited abnormally with [1]
Sep 28 03:14:47 iscsid: connect failed (111)
Sep 28 03:14:51 iscsid: connect failed (111)


Happends overnight just out of nowhere, rescue mode doesn't really help, server doesn't respond in normal mode, the support does absolutely nothing to fix this so im pretty much stuck with reinstalling, something which i'd rather not do..

Mick
08-06-2009, 22:27
mmmm interesting read,

Has support improved any better ?

rno
08-05-2009, 10:31
Quote Originally Posted by Seedbox Paradis
Ok, seeing as you're having loads of problems with the RPS, maybe get a Kimsufi... There won't be issues with the iSCSI connections or any other bull.
Changing for something else could be a solution, but it's not the kind of answer that I'm expecting.

Seedbox Paradis
06-05-2009, 14:15
Ok, seeing as you're having loads of problems with the RPS, maybe get a Kimsufi... There won't be issues with the iSCSI connections or any other bull.

rno
06-05-2009, 09:05
Quick update...

it's a good few months since my last post/issue... I've reinstalled one RPS because I could not wait anymore and tried to reboot the other one once more and it boots up!

I do believe that iSCSI was the issue but nobody from OVH help me, not even been bother to send me a mail! I reckon it's because OVH is cheap!

Anyway... now it's working but this morning I've spot in the log 100 lines like that:

kernel: connection1:0: ping timeout of 5 secs expired, last rx 1308982925, last ping 1308984175, now 1308985425
iscsid: connect failed (113)
kernel: connection1:0: detected conn error (1011)
iscsid: connect failed (113)
last message repeated 4 times
iscsid: connect failed (111)
iscsid: connect failed (111)
iscsid: connection1:0 is operational after recovery (198 attempts)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (23 attempts)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (15 attempts)

Since my issue, i've put together a bunch of script to restart service such as "ssh", failed last night and restarted! (I'm so glad I've put this script in, otherwise I would have reboot the box and the box would have not reboot because of the iscsi issue, and I would have spend my day trying to get someone from ovh to fix it! crazy world!)

I will keep you up-to-date if I lost my RPS once more time!

rno
06-03-2009, 14:36
Quote Originally Posted by rno
This can be the reason or it could be something else, I reckon we could guess for a long time without consoles access it will be only guess, anyway I should not have to worry about such things, I'm renting hardware, and I'm not suppose to take care of the SAN.

To be honest I'm still amaze, this is "SO BAD" and no one from the support seems to be bother about this post, so with an RPS you are in this situation where if anything happened the only solution seems to reinstall, come on "HOW BAD IS THAT???" I'm Unix sys admin, it's my job and I've been doing it for years, came across many issues where console was the only solution to solve them, the more I think about it the more i think that renting an RPS is a waste of money, because this is not reliable so you won't be able to run any thing important, even a mail server... what's going if your mail server is off for 2 days?, and please don't tell me it's cheap and this is great for testing! I've got my linux box at home to do so!

I'm really piss off about this situation and I'm still waiting for answer from OVH peoples!
Quote Originally Posted by Neil
Hi

What is your Nic Handle or server address? When booting from the servers kernel on an RPS it can take up to 30 minutes for it to boot up.
I've got 2 RPS, and they both refused to boot up... I've reinstalled one, for the sake of testing, and just reboot the other one 10 minutes ago and it's now working (tryed many times before), so it was an OVH issue and not my fault, but had 2 weeks of outage, and had to redo the setup of one RPS...

My nickhandle: ma35510-ovh

Neil
06-03-2009, 12:59
Hi

What is your Nic Handle or server address? When booting from the servers kernel on an RPS it can take up to 30 minutes for it to boot up.

rno
06-03-2009, 11:25
Quote Originally Posted by jpl.name
If the system was unable to connect to the iSCSI drive, it's quite normal the log seemed to be frozen...

And you cannot boot on a factory-RPS without the iSCSI connection.

This can be the reason or it could be something else, I reckon we could guess for a long time without consoles access it will be only guess, anyway I should not have to worry about such things, I'm renting hardware, and I'm not suppose to take care of the SAN.

To be honest I'm still amaze, this is "SO BAD" and no one from the support seems to be bother about this post, so with an RPS you are in this situation where if anything happened the only solution seems to reinstall, come on "HOW BAD IS THAT???" I'm Unix sys admin, it's my job and I've been doing it for years, came across many issues where console was the only solution to solve them, the more I think about it the more i think that renting an RPS is a waste of money, because this is not reliable so you won't be able to run any thing important, even a mail server... what's going if your mail server is off for 2 days?, and please don't tell me it's cheap and this is great for testing! I've got my linux box at home to do so!

I'm really piss off about this situation and I'm still waiting for answer from OVH peoples!

jpl.name
05-03-2009, 20:41
If the system was unable to connect to the iSCSI drive, it's quite normal the log seemed to be frozen...

And you cannot boot on a factory-RPS without the iSCSI connection.

rno
04-03-2009, 18:37
Quote Originally Posted by jpl.name
Did you check the RTM (Real Time Monitoring) in the manager, and OCO (OvhCheckOut) via Telnet when this event occured?

Maybe the RPS could not mount the iSCSI drive...
No did not, but even the reboot was failing, and no things in the logs... I kept the log just in case!

jpl.name
04-03-2009, 16:36
Did you check the RTM (Real Time Monitoring) in the manager, and OCO (OvhCheckOut) via Telnet when this event occured?

Maybe the RPS could not mount the iSCSI drive...

rno
04-03-2009, 14:59
This storry happend today... the 4th of March

rno
04-03-2009, 14:57
Using Centos 5.2

On the 27th of feb at 5am by RPS stopped working... could not log on anymore!

I've created a ticket, asking support to have look (because a DB was running, did not want to reboot it), anyway after 2 more days i've decided to call the support and I've been told to boot in "rescue - mode", I've argued my point about the DB running and I did not want to reboot it, and.... but it did not work out!

So i've rebooted this RPS in "rescue mode", mount /dev/sda1, chroot, and checked at the logs, and just realised that the last log were written on the
27th of feb at 5am, not saying much btw... (no things important).

Tried to reboot it in "normal mode" and nothing... so back to rescue mode, checked the log again and nothing changed.... so the RPS does not even boot up!

I've checked the yum & rpm logs, was I crazy? Did I install a unstable-testing packages... NO grub, NO lilo, NO kernel installed… so this RPS was running using the default kernel and using the default boot loader!

So with all those information I've decided to call back to support begging for a console access, to see what was the output on the screen or terminal, I've been told that they could not provide me a console, so I've asked could you check the console, but they could not and they will not send some to check the screen in the datacenter because the hardware was fine and could only be my fault because with root access I could have break something (which could make a lot of sense, I have to agree, but I was providing some good information… anyway) after 25 minutes, I've end up by reinstalling the RPS, it's now all fine and working.

So run again yum upgrade, setup the firewall

/sbin/iptables -A INPUT -i eth0 -p icmp -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -j DROP

/sbin/iptables -A INPUT -i dummy0 -p icmp -j ACCEPT
/sbin/iptables -A INPUT -i dummy0 -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -i dummy0 -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -i dummy0 -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A INPUT -i dummy0 -j DROP


Reboot to be sure that it was all fine and working.

To resume the situation, something went wrong and I've got no idea of what happened and this is scarry, this could happened again at any time and will not even be able to have console output telling what is going on!

I was planning on using OVH for projects within my company but I can't anymore because the unstable nature of this hardware and mainly because there is no advance support, if I can call a console access "advance support"

Hopefully you will give me answers…
rno