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
yes
@VirMach
Could anyone tell me where to get the login information for VNC.
I connected with VNC IP:PORT and Passport, but I cannot login to my VPS.
I tried user root and password for root, as well as SolusVM user and password. All returned "login incorrect" message.
Thanks.
@VirMach
Could anyone tell me where to get the login information for VNC.
I connected with VNC IP:PORT and Passport, but I cannot login to my VPS.
I tried user root and password for root, as well as SolusVM user and password. All returned "login incorrect" message.
see the snapshot: https://ibb.co/7KdLL8X
Thanks.
ahh, now laxa014 joined laxa024. vps down with error:
Operation Timed Out After 90001 Milliseconds With 0 Bytes Received@VirMach if laxa024 really online, please bring my VPS up
action=productdetails&id=256420Alternatively you can resize VNC view to see and click "show" near the VNC pass and use proper VNC password... It's not that hard
Use TightVNC Viewer or something.
@VirMach My vps expired on April 7, 2023, but it was terminated today.
Ticket #436175
same for Seattle location, i mean my Seattle VPS went offline
Operation Timed Out After 90001 Milliseconds With 0 Bytes Received
Most of my services are down,
I had this particular issue on my LAXA031 VM too where I'll get login incorrect.
I regenerated the password a few times and I was finally able to login to the server with VNC.
Not sure what the issue was, could be me (had a few zeros and Os in the password).
If you click VNC from Solus (rather than WHMCS/billing) there is this awesome button
Every server I own is online and it's working.
Almost every server has working VNC - except one on
NYCM101- ends with some garbage output. @VirMach any idea what is this, this is something node related and you guys forgot some settings or this is my VPS related and who the hell knowNo, clicking random buttons do not show correct text.
Yes, server is online, I can ssh.
Yes, tried some standalone Windows app (TightVNC, VNC Viewer) - ends the same.
some live In the future ! Welcome to the future!!
This looks like Ubuntu 20.04 LTS broken VNC console to me... Try to reboot it while the VNC Window is open, and see if you can see the Ubuntu version if you connect quick enough. SSH should work OOB though
P.S. It's either 18.04 or 20.04 LTS in my testing.
I expect that @xpreboun is correct that this is not a problem with the node and is O/S related as I have a VM on node NYCM101 with AlmaLinux8 and the VNC works fine in the billing panel, SolusVM, and TightVNC.
SJCZ004 and FFME006 back online.
SEAKVM9 still down.
SEAZ005 no new IP assigned.
I start VPS in Tokyo from May, 26. It is down day by day. After 1 month and a half. I can use it for only 3 days.
. Terrible quality for a long time.
Yeah, the issue with my node is VNC only worked on the billing panel itself. clicking Solus just returns error on the page (with no redirect).
Finally, after 2 weeks of downtime my FFME002 VPS is now working
YABS for new Ryzen server (Prev GB5 result: 572, 3001)
The fact that it is still valid,But now it seems that the FFME005 node seems to be restored
Your service was suspended for: Network abuse. Please appeal your suspension by clicking the green button above. Otherwise, please cancel your service to avoid service renewal.
Fuck me right?
Is there a green button?
Was this by chance resolved? I'm on two different NYC servers and both are still very slow.
Same
Can you be more clear on your issue? Is it online, or can it not boot? Do you mean the VM is "online" but it cannot boot into the OS? What error? It's extremely rare for it to both come online and also not run your image.
All VMs on that node were already cleared off outside of 1 single VM which we're tracking.
As we get into the last tiny percentage of those still having issues, it becomes exponentially more time consuming to resolve. I'd say 99.5% of them if not more are complete and online at this point, and the most those should require is a network reconfiguration, whether it be automatic using the button or manual within the VM which you should have full access to via VNC.
If this was recent you for some reason had it set to use the main node IP and it was causing DHCP issues and knocking off the panel and causing node-wide packet loss or something to that effect.
It's theoretically possible it's some bug but then we'd probably see it more widespread. Maybe it's a combination of things but it's not even on the same range or for SolusVM to utilize. We have to be strict on IP stealing for now until we can get the automatic protection working better but seeing as you're registered here since 2017 and if I recall correctly you've had the service for some time we'll be lenient and by default assume no malicious behavior, we just had to suspend it for now to prevent it from happening again. You'll most likely remain suspended for at least a few days until things cool down, sorry. We'll provide SLA credit if the problem was on our end.
I remember seeing this problem when we were doing OpenVZ to KVM conversions. I don't remember the fix but it was simple. It'd also make sense if you're facing the issue again if it was originally OpenVZ but honestly we're still in uncharted territory for the most part right now so it could be a similar but different issue.
I'm expecting more weird and rare issues like this to pop up. So far Ubuntu 14 w/ desktop likes getting stuck on OS selection screen and maxing out CPU, some versions of Ubuntu 16 likes kernel panicking even with modified CPU settings, I believe Debian 8 or 9 or something like that likes kernel crashing hardcore and almost knocking a node offline but that's rare and not for all of them, Windows likes being Windows and providing extremely vague error screens, and either Debian 9 or 10 likes making it to the login screen and then still overloading. This is the first report of that VNC issue though, that I've seen. I haven't seen any in person.
Luckily all these issues probably only affect 2-3% and they're not fatal.
We're still working on it, these are mainly related to the above. Each node still has maybe around 5 VMs going into crash loops which has an impact of greater than around 20% CPU steal on the node.
Some are handling it better than others just because they're only half filled.
This might just not have any templates because the template sync for it failed several times. Not related to the node, just SVM being overloaded.
I migrated from Buffalo to Phoenix manually, but perhaps I should have waited for the forced migration and looked forward to what issues I would encounter.