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.
★ VirMach ★ RYZEN ★ NVMe ★★ $8.88/YR- 384MB ★★ $21.85/YR- 2.5GB ★ Instant ★ Japan Pre-order ★ & More
This discussion has been closed.
Comments
I have a VPS which was forced migrated to RYZE.DAL-Z008.VMS but VNC just displays "dev/vda1: clean, 103910/2268480 files, 2001311/9108944 blocks".
Press enter few times, see what else will show up. This seems normal.
Fortunately, I am 5%. The fact is that the VPS down for almost a month, and your console will not lie.
Nothing has changed since pressing enter (I have also rebooted the server a few times)
@VirMach
i have two vps,
one vps id is 562342 in Node DALZ007
other vps id is 615853 in Node DALZ009
the two vps all can not BOOT , Reboot ,VNC ,Re-install os , and can not SSH , ping is time out .
this twp vps is bad longtime .
please check Node DALZ007 and DALZ009
thank you .
@VirMach
My VPS on SEAZ010 node looks like woke up. And after a simple 'network reconfigure' working fine at the moment. Thank You!
But my VPS on NYCB019 node looks like working in the background, but technically "unreachable" for me. Sometimes the webserver loading slowly, but most of the time no, I'm not able to login (SSH). The WHMCS say: Operation Timed Out After 90001 Milliseconds With 0 Bytes Received
Sky high steal in Tokyo storage node is a bigger problem than not having 10G. I see > 30% so often.
I literally can’t type in one single line of command without few times of stutters since day two. Day one is fine then after mass deployment(?) it’s never been smooth again.
hi @VirMach my NYCB019 node has been dead again for ~30 hours. Please fix thanks
Same here as well, I opened a ticket earlier today. Full node name is RYZE.NYC-B019.VMS
Can't reach from Billing site or SolusVM.
@VirMach over 2 weeks ago i ordered and paid the migration of my server.
Invoice 1456026, still not migrated.
The technology is poor, the temper is bad, and seeing your reply is very disgusting. I think I have been busy a lot in the past six months, but for the user, you have done nothing, and have not dealt with it since Tokyo. Now repairing other locations, You should clear the user!
I just noticed my reply here got cut off.
I think I went into how you were saying the data is important but it was an outage report and a network issue maybe and how we were working on it and waiting for DC for a long time. I don't remember, sorry. The message was definitely a lot longer and wasn't just about no email notification portion.
@Virmach are you going to keep NY10GKVM61 or retire? It never connected to Solus nor had any migration button...
You can just delete and allocate new one with same spec anywhere.
@VirMach RYZE.DEN-Z001.VMS, only Centos 6,8 & 7 + debian 8 & 9 ISO's. Can you add Ubuntu / netboot.xyz ? I need Ubuntu with custom partitioning...?
Look like @VirMach making some mistakes, issues again with iso repos on some nodes
SJCZ004 was a happy server for a couple of weeks.
Today, down and nothing on the server status page.
ATL has been a real trooper. knock on wood
I do make mistakes but this isn't one of them, this is still the sync feature in SolusVM running into various issues. We're making progress but it's slow. It has to constantly e re-started.
I'm actually queueing it up all day. About halfway done.
We stopped using the status page temporarily as so much is going on to where we can't reliable provide updates. I understand this is a terrible way to treat it and as soon as things calm down a little bit over the next week we'll resume updates when we're able to again provide meaningful updates. Right now though it's counterproductive because it will take out 1-2 hours of our time every day that can be better spent dealing with the issues.
Of course this is a little subjective and you might find it extremely important and worth the time spent, in which case my counter-point would be that a lot of times by the time we're aware of the issue to make a status update, we usually immediately resolve many of them. And clustered updates will make the other more important messages sink.
In the case of SJCZ004 we actually were not aware until your comment, and that's because of an issue with the monitoring that I've been fixing over the last hour. I just took a pause to eat lunch and check comments here and I was resuming fixing the monitors. So it would have probably taken another 30 minutes to an hour. Now that it's fixed I can see this has been down for nearly 3 hours and I'm working on getting it back up but it looks like the DC has to get involved as it's stuck in a weird state where power button has to be used. I'll see if I can make an update for servers waiting on DC as they may take longer to resolve.
NYC problem again, WTH guys? Just halt those migrations theres no point in turn your customers life into a misery
Those lonely Buffalo dedicated servers are expiring left and right.
VirMach could halt migrations, but that just means your unmigrated services would just go down and data lost permanently.
If that is what you want, you can achieve the same by pressing the "cancellation without refund" button.
I am very happy to see that they have fixed this on their own. @VirMach What is the plan to get the additional IPs back? Should a ticket be created or are they going to be fixed by you as bulk-update? Thanks!
Thank you, I've been using your service for 2+ years, your server is excellent, but it would be better if you can give more notice when changing IP.
These reboots still ongoing? Going on for about six hours now.
Nothing we can do about it. NYC has some problems waiting DC hands and last contact was several hours ago with no results.
Tokyo network improvements have completed. You should see a noticeable difference now.
I agree with you completely, we just can't operate that way right now due to the volume of the tasks. If we had to pause and provide notice every time it would extend these changes for weeks if not months. Once we resume regular operation we'll go back to providing ample notice for any future changes and I apologize.
This should be improved as well, at least on the direct network and CPU side. Any disk wait will still continue to cause load spikes.
It's most likely going to be tickets and most likely a button that says "Claim IP" and requests the relevant information and disclaimers (such as VPS may require migration.)
ping.pe, TYOC039, after network improvements
Why did my VPS just get turned off for 'high amounts of CPU'? According to the email the VPS was using 203.05% CPU, assuming 'CPU' means a (v)Core then I was only using 2 out of my VPSes 8 assigned cores with the AUP stating "[you] cannot average higher than 50% usage within any two (2) hour period".
I also checked htop yesterday and across all cores the CPU usage was sitting around 3-10% max.
Reply to the ticket so we can look into it, if you already haven't but I looked through these recently since we made changes to the abuse script. Most of them are for 99% on 1 core but it's possible it's making a mistake in which case you'd be provided with SLA credit and the script modified.
The script does take into account how powerful the CPU is when making calculations as well as if your plan is designated "KVM Lite" or advertised as 33% instead of the usual 50% AUP. Just like with everything else if a plan is initially advertised in a way that's different and clearly laid out on the plan itself, it may not follow our standard AUP/terms. So if a package is marked as no support, then it would overwrite anything in the terms about getting a certain level of standard support. We do also have portions that allow us to make these changes without changing the terms of service every time we offer something different. It's possible the system went 800% on a standard 2660v2 and then if you're on a 3.5GHz Ryzen, lowered the baseline to about 600% and if it's also a 33% package then anything above 200% for several hours would be outside of those bounds but there should also be bottom limits. Maybe those are not functioning properly.
It also depends on when it happened, if the node was overloading in some way then it would allow it to go to the actual bottom threshold. I'd need to see your ticket to see what happened.
Replied