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
Mine is up
same i checked here. mine is also up. i rebooted it and it started.
did you got any reply from support? i got late reply in past.
mine went down around 9-10 hours ago but it's up now
Mine is up, but maybe mine is in another node
Thanks for confirming! Mine still can't start so I'll wait to get a reply on my ticket. I forgot to use the "emergency" checkbox when creating the ticket and don't see a way to set that after creating the ticket🤔
They've screwed up something in the routers and MTU detection isn't working. That's why it is pinging OK for some people. Set the MTU manually and you should be right.
I literally can't even boot my VPS. Clicking the start button says that it was successfully booted, but the control panel still shows it as "stopped".
Yeah OK that's different. Mine was just network.
Turns out there was an ISO mounted that completely prevented it from even booting. Not sure how that happens, and I didn't even see it in their control panel to unmount (maybe a deleted ISO?). They unmounted it on their end and now it boots again.
/thread
I've only noticed that IPv6 stopped working. When I opened a ticket, their first response was:
I told them that they did provide IPv6 until an hour ago and got:
Roughly at the same time IPv6 connectivity was restored. 🤷
Somewhere I saw they'd officially drop ipv6 in Sydney although I also have ipv6 in Sydney.
I had the same issue today. Network was all over the place so changed the MTU to 1400. Later in the day (8:30pm AEST) I lost full connectivity. Couldnt use console to connect through the portal either. Raised a ticket and was told that due to a iso/CDROM being boot that it was preventing startup. Very strange.
Correct, this happened about 7-8 months ago and everyone affected was notified.
That has not changed and we do not support IPv6 in Sydney.
Really weird that a mounted ISO can completely prevent the system from booting (at least that's what I saw in my case).
I thought you were going to switch to a new network provider in Sydney to fix the issues with the network?
I do have another VPS in Sydney with another provider that has stable IPv6, so I already moved most of my apps that require IPv6 off the HostHatch VPS onto that one instead. I guess I could do some sort of tunnel from the other VPS to get more reliable IPv6 connectivity on the HostHatch VPS? I'm already at the limit of 5 tunnels in tunnelbroker.
Email dated 26th July 2021:
This is a known SolusVM issue in case of an unexpected reboot. VMs with mounted ISOs do not come up.
In the new control panel, this is fixed by design. There is no "boot order". If you mount an ISO, the server is booted from it automatically. And you have to remove the mount to boot back into the hard disk. So this problem cannot happen. Some other providers do it this way as well (I believe Hetzner for example).
We have nearly moved already (it's been slowly ongoing since early this year) and stable IPv6 will be fully available soon for everyone. I believe your VM is already on the new network (in case you want to run new benchmarks).
I was just pointing out that at this time and since the past July, we do not support IPv6 in Sydney for the people who received the email you copied in your comment.
Ahhh TIL. Of course it's a SolusVM problem, I should have guessed. What does SolusVM actually do properly?? haha
Thanks for the info! So IPv6 should be stable for me? That's really good to know; I can move some stuff back onto this VPS
How can I tell if it's on the new network?
I just re-ran traceroutes to various servers globally and no more Telstra Global but now using Cogentco. It does seem far more stable to local traffic and routes to cloudflare and google which is great! On a couple of routes to US/CA, the latency is approx 20ms higher haven't checked throughput though.