New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Well you do have the option of pausing or rebooting the domain in xen rather than issuing a destroy you only really need to issue a destroy in xen if the vps is under such load that it is unresponsive to a shutdown or reboot.
I'll admit when it comes to KVM I have very limited knowledge (we have very few KVM clients and I like to keep it that way so I can focus on OpenVZ). I'll look into the suspend option and see what it does in the event I need to use it in the future but as a rule of thumb we suspend VPSs as a last resort and we would never automate a suspension except for billing.
A reboot is a graceful reboot (i.e. shutdown services before restarting)? Do clients have the ability to unpause a VPS?
Anyway, I think the thing echoed by providers here is that if 1 is causing problems for many then the 1 gets taken out of the equation, you could transfer this to a number of businesses and it is totally reasonable.
The exception here is if that 1 is paying for fully managed support, but that is only because this situation should never have happened to start with because the host is directly responsible for ensuring the 1 VPS under management is correctly managed to begin with.
If your managing your own VPS and it becomes a problem you only really have yourself to blame if it gets shut down.
Suspending seems like a good idea, at least then you can give the client a chance to sort it once they've been informed of what's going on. (or at least let him know) without causing any major inconvenience.
The exception to this rule is if a client is paying you $1000/month and it is impacting 100 clients paying $1/month... in which case you move the $1000/month client to his own server.
I have all my production setup scripted as I do the same thing over and over. If your "production" VPS is not ready, nothing is effect if it is restarted, is there? Also doubtful you get caught by a monitoring script as you are not doing anything either. But let's take your desire and see what is really needed, to do something simple like email the client.
Alert client for PID for CTID X
pole master for CTID SolusID
pole WHMCS for SolusID email
email client
So now the client has been emailed, but by the node, so probably in their junk folder and ignored. How long do we wait for them to ignore this before stronger action is taken, all the while, others on the node may be affected by this process runing wild. Or we could just restart the VPS and all these other cliwnts who are also paying customers are not bothered and life goes on.
I see your point you are trying to raise, but as a provider, if I upset you, you leave, if you upset everyone else on the node, they leave, so do I upset 1 or many? Economically, I upset one as the least evil.
This is a good option if the client doesn't mind waiting hours for somebody to unsuspend their VPS. In the instance of a small operation like us it could be 12+ hours before we get around to it which is why we like the reboot option so clients don't have to wait for manual intervention to get back online.
@Maounique
By connecting to a server via vnc, you are wasting the same amount bandwidth, power and others things
@KuJoe
xm reboot is a graceful reboot, if the client hits the reboot button on a paused domain it will unpause it and do a graceful reboot or they can request that you unpause the domain too.
then you have the vcpu-set and pin facility to prevent long term abuse of multiple cores etc, teh xl toolset now has the 'button-press' facility "button-press Indicate an ACPI button press to the domain" which can be handy when something becomes very unrespocive before going straight for the destroy.
I know Xen was dropped from RHEL in favour of KVM but its making some great advancements and 4.2 offers great performance boosts.
Assuming the node is able to send e-mails. How long would sendmail take to process a queued e-mail if the node level is 100+?
@AnthonySmith You're making me want to revisit offering Xen again... DAMN YOU! :P
I know, I was just trying to entertain @spycrab101 why his idea is more work than it is worth, just too many thing to go wrong, instead of your clean and simple solution that simply ends the problem and effects the fewest clients as possible.
as for the email/spam I would suggest swapping the MTA for postfix so you can specify a relay to prevent it being seen as spam if anyone is thinking of scripting it.
@KuJoe and with all the scripting possibilities in OpenVZ to make a node near abuse proof you are making me want to break my promise never to touch OpenVZ
@miTgiB you are right though, while we could all sit here and scrip stuff until the cows go home just because someone did not bother to look after their container or consider the consequence the reality is, you don't upset 100 customers because 1 is not being responsible.
@KuJoe
I wouldn't mind as long as it's done for a good reason. At the end of the day if someones VPS has 100% cpu usage then then most likely don't know about it and would be happy to be told about and and therefore the host or client can correct their mistake. I'm sure they wouldn't mind waiting considering it was their fault (possibly unknowingly) in the first place.
@spycrab101 I cannot think of a single instance where by it would not be a good reason, no host sets out to upset customers, you can be sure that if your server has been rebooted it is for a good reason.
on a side note @Kujoe how about echoing the ctid to a separate file then rebooting it, if the ctid is still in the file in when it is next abusive it gets shut down instead and the ctid is removed from the file.
Just thinking of the art of the possible I am not saying you should do that
Give the client a choice to be suspended or rebooted then? This could be set during the ordering process.
You should write it, isn't that the perfect OpenSource response?
By connecting to a server via vnc, you are wasting the same amount bandwidth, power and others things
looks like you didnt get the idea...
They are using scripts to "watch" a set of videos to increase the watched count. They can sell their services to ppl or trade them for other "watching" machines, they just go without user input, fully scripted, like i have 10 VPSes "watching" videos, only need to feed them the url and i get it from an exchange automatically in exchange to my URLs that the other ppl with scripts are "watching".
The VPS owner does not really watch anything, it is the scripts that do so he uses no bw with vnc and other things, the VPS goes on automatically, a robot to watch youtube.
This person wants it this way, that person wants it that way. There are no perfect solutions. No matter what you do, it's going to piss off someone. This is why the best solutions tend to be minimal and effective.
You are saying that as if you think scripting it is as simple as:
If we could knock up something like your suggesting in 10 minutes we would be competing with WHMCS not selling VPS's
As soon as you implement this feature I am signing up with Inception
That's not a bad idea. We do something similar for other scripts and it would prevent some unwanted e-mails.
Something like this (not actual code but gives you an idea):
$ctidcheck = cat /var/log/$ctidcheck.log if ($ctidcheck > 0) vzctl restart $ctid echo "$ctid" > /var/log/$ctidcheck.log else vzctl stop $ctid echo "0" > /var/log/$ctidcheck.log fi
What tags did you use for that box?
pre
bah, now you have done it, I cant resist any longer!
@miTgiB can I buy a semi decent KVM VPS from you pl0x I think I need to set up an OpenVZ test bed
I'll have what he is having.
Thank you good sir. I love learning new things from threads like this.
haha, well you know, that's just how I roll, some hosts like their fancy autoboot, ... I decided to go with the autotoast
I never thought in a million years a thread about VPS node abuse would actually convince somebody to start using OpenVZ (not saying OpenVZ is bad, just saying that it's known for the potential abuse if not managed correctly). :X