Hahahaha....
I only have 3 in virmach, the others I have more at other service providers (gxxx, axx, rxxx, bxx)
Never experienced anything strange like this, before I requested according to hostnane and was not responded to, are you a virmach employee?
In my 2 vps, virmach ColorCrossing, once requested rDNS to my hostname and returned it to IP, there is no such slow process.
@vgood said: request to change my new rDNS VPS to IP only but the ticket was closed by virmach
Therein lies your problem. If you'd have requested a match to your current hostname, then it's normally done almost immediately.
Your unnecessary Ticket will add $5 to your renewal price. /s
(3x Virmach VPS = amateur. )
Nope.
Can't tell exactly, 'cos I can't login but have about 12 active VPS of which about 9 are actually utilised. I always match rDNS on servers that are being used. It used to be a manual Ticket process, though now it's pseudo automated from a button in the Client Area (which creates a Ticket).
It wisnae me! A big boy done it and ran away.
NVMe2G for life! until death (the end is nigh)
That's strange, why in my previous 2 vps, it was enough to go through the existing menu and the process didn't take long time and only took half a day. on this new ryzen vps, I asked through the menu and waited 10 days it didn't change to the hostname, I decided to send a manual ticket and asked to return it to the IP, but the result is the same. I'm confused.
Nope.
Can't tell exactly, 'cos I can't login but have about 12 active VPS of which about 9 are actually utilised. I always match rDNS on servers that are being used. It used to be a manual Ticket process, though now it's pseudo automated from a button in the Client Area (which creates a Ticket).
@vgood said:
That's strange, why in my previous 2 vps, it was enough to go through the existing menu and the process didn't take long time and only took half a day. on this new ryzen vps, I asked through the menu and waited 10 days it didn't change to the hostname, I decided to send a manual ticket and asked to return it to the IP, but the result is the same. I'm confused.
Nope.
Can't tell exactly, 'cos I can't login but have about 12 active VPS of which about 9 are actually utilised. I always match rDNS on servers that are being used. It used to be a manual Ticket process, though now it's pseudo automated from a button in the Client Area (which creates a Ticket).
ohh, thanks for the information, if there is information like this from virmach then it will be clear. so I don't expect anything else to be a misperception. thanks for the explanation.
@vgood said:
That's strange, why in my previous 2 vps, it was enough to go through the existing menu and the process didn't take long time and only took half a day. on this new ryzen vps, I asked through the menu and waited 10 days it didn't change to the hostname, I decided to send a manual ticket and asked to return it to the IP, but the result is the same. I'm confused.
Nope.
Can't tell exactly, 'cos I can't login but have about 12 active VPS of which about 9 are actually utilised. I always match rDNS on servers that are being used. It used to be a manual Ticket process, though now it's pseudo automated from a button in the Client Area (which creates a Ticket).
Is there a way to get a console for a system when billing.virmach.com isn't responding that doesn't require me to have thought ahead and written down the link for that specific server?
@skorous said: Is there a way to get a console for a system when billing.virmach.com isn't responding that doesn't require me to have thought ahead and written down the link for that specific server?
In my understanding, no.
EDIT:
Except in the activation email under
Advanced Control Panel
If you would like to access your control panel independently, you can use the direct link. Your username is "thisisyourusername" and you must reset your password to obtain it.
@vgood said:
Hahahaha....
I only have 3 in virmach, the others I have more at other service providers (gxxx, axx, rxxx, bxx)
Never experienced anything strange like this, before I requested according to hostnane and was not responded to, are you a virmach employee?
In my 2 vps, virmach ColorCrossing, once requested rDNS to my hostname and returned it to IP, there is no such slow process.
@vgood said: request to change my new rDNS VPS to IP only but the ticket was closed by virmach
Therein lies your problem. If you'd have requested a match to your current hostname, then it's normally done almost immediately.
Your unnecessary Ticket will add $5 to your renewal price. /s
(3x Virmach VPS = amateur. )
If you're speaking of rDNS on Ryzen, you can assume long waits and potentially for the request to not be filled for now. None of the systems are built for that yet. With CC, we coded it out using their API. We do not consider rDNS critical and those tickets will most likely not be answered until we clear out the entire ticket queue.
Some guy made like 11 tickets for the same rDNS and I'm going to make sure we answer his absolutely last.
@reisenpai said: And we got scheduled reboot/shutdown on 039 again. This time, we can't even boot it manually.
Can you issue a boot up for everyone on 039?
If I am correct users on Node39, which was a beta test node, are being migrated to a different node.
EDIT: This was misinformation.
As I misunderstood what this comment was referring to:
[@VirMach said]: The node was attacked in other ways and SolusVM eventually ran into deeper issues. I'm still trying to get it back online and once I do, we'll be migrating it to another node completely.
@reisenpai said: And we got scheduled reboot/shutdown on 039 again. This time, we can't even boot it manually.
Can you issue a boot up for everyone on 039?
If I am correct users on Node39, which was a beta test node, are being migrated to a different node.
Nothing scheduled like that and the node is up. I get a lot of reports by a lot of people that that node keeps going down and it's just been up the whole time, I have no idea why people are saying all these things honestly. I guess because it was called beta test node or reported as having issues at some point in time everyone immediately assumes that as the default explanation for everything related to their VPS going offline or even SolusVM running into issues?
Anyway, my guess is that the "we can't even boot it manually" part is related to the fact that SolusVM is down.
@reisenpai said: And we got scheduled reboot/shutdown on 039 again. This time, we can't even boot it manually.
Can you issue a boot up for everyone on 039?
If I am correct users on Node39, which was a beta test node, are being migrated to a different node.
Nothing scheduled like that and the node is up. I get a lot of reports by a lot of people that that node keeps going down and it's just been up the whole time, I have no idea why people are saying all these things honestly. I guess because it was called beta test node or reported as having issues at some point in time everyone immediately assumes that as the default explanation for everything related to their VPS going offline or even SolusVM running into issues?
Anyway, my guess is that the "we can't even boot it manually" part is related to the fact that SolusVM is down.
Mine is also on 039 node and it’s suddenly down a while ago after 1 day stable.
Here is the metric: https://tz.115.al/Detail/BEEEE74D
@reisenpai said: And we got scheduled reboot/shutdown on 039 again. This time, we can't even boot it manually.
Can you issue a boot up for everyone on 039?
If I am correct users on Node39, which was a beta test node, are being migrated to a different node.
Nothing scheduled like that and the node is up. I get a lot of reports by a lot of people that that node keeps going down and it's just been up the whole time, I have no idea why people are saying all these things honestly. I guess because it was called beta test node or reported as having issues at some point in time everyone immediately assumes that as the default explanation for everything related to their VPS going offline or even SolusVM running into issues?
Anyway, my guess is that the "we can't even boot it manually" part is related to the fact that SolusVM is down.
Mine is also on 039 node and it’s suddenly down a while ago after 1 day stable.
Here is the metric: https://tz.115.al/Detail/BEEEE74D
I wouldn't be able to help anyone here until SolusVM comes back online but I can assure you that the node is online and also not running into the same disk issues it did in the past. It's possible that something else went wrong with the node, but not likely. I'd guess something went wrong within the VM and now since SolusVM is broken it's not possible to boot it back up from your end.
@skorous said:
Is there a way to get a console for a system when billing.virmach.com isn't responding that doesn't require me to have thought ahead and written down the link for that specific server?
The billing area should be working fine, I think it's just not connecting to SolusVM since that's down, and it may cause it to throw errors or not load your service page.
@AlwaysSkint said: It used to be a manual Ticket process, though now it's pseudo automated from a button in the Client Area (which creates a Ticket).
It actually became fully automated, we just kept it pseudo automated looking on the customer's end. It also helps us use it as a sort of visible log and step in if the system breaks.
But it's not automated at all for Ryzen.
(edit) It's very likely that for Ryzen, we'll just finally enable the actual automated feature on SolusVM. But with it we may also do default port 25 blocks, that can be removed either for a fee or for trusted customers.
@reisenpai said: And we got scheduled reboot/shutdown on 039 again. This time, we can't even boot it manually.
Can you issue a boot up for everyone on 039?
If I am correct users on Node39, which was a beta test node, are being migrated to a different node.
Nothing scheduled like that and the node is up. I get a lot of reports by a lot of people that that node keeps going down and it's just been up the whole time, I have no idea why people are saying all these things honestly. I guess because it was called beta test node or reported as having issues at some point in time everyone immediately assumes that as the default explanation for everything related to their VPS going offline or even SolusVM running into issues?
Anyway, my guess is that the "we can't even boot it manually" part is related to the fact that SolusVM is down.
Edit:
When I says offline or shutdown or reboot, I'm talking about the VM, not the node.
Whenever I reboot the VM within the OS, there is a fair chance for it to go offline until manually booted in the panel.
The reason I said automated or scheduled shutdown is the fact this always happens on 08:00 PST.
I know the node itself is running alright, it's the VMs being offline.
People mistakenly reported it as Node being down because they didn't realize they can just boot the VM up.
@reisenpai said: And we got scheduled reboot/shutdown on 039 again. This time, we can't even boot it manually.
Can you issue a boot up for everyone on 039?
If I am correct users on Node39, which was a beta test node, are being migrated to a different node.
Nothing scheduled like that and the node is up. I get a lot of reports by a lot of people that that node keeps going down and it's just been up the whole time, I have no idea why people are saying all these things honestly. I guess because it was called beta test node or reported as having issues at some point in time everyone immediately assumes that as the default explanation for everything related to their VPS going offline or even SolusVM running into issues?
Anyway, my guess is that the "we can't even boot it manually" part is related to the fact that SolusVM is down.
Whenever I reboot the server within the OS, there is a fair chance for it to be offline in the panel until manually booted.
The reason I said automated or scheduled shutdown is the fact this always happens on 08:00 PST.
I know the node itself is running alright, it's the VMs being offline.
People mistakenly reported it as Node being down because they didn't realize they can just boot the VM up.
And I highly doubt it's a problem within the VM, multiple people with different templates and ISO are having the same thing.
Edit:
And just to be clear, we have two problems:
1. VMs goes offline from time to time, but it's always at 08:00 PST. All we need to do is manually booting it in the panel.
2. Whenever we reboot the VMs within OS, there is a chance for it to go offline. And we boot it in the panel.
@VirMach said: The billing area should be working fine, I think it's just not connecting to SolusVM since that's down, and it may cause it to throw errors or not load your service page.
Yeah, not a huge deal. I rebooted an idler today and forgot it doesn't have automatic encryption unlock yet. I'll take care of it when they give up.
@reisenpai said: Ms goes offline from time to time, but it's always at 08:00 PST. All we need to do is manually booting it in the panel.
Who is we? I need to know exactly what list of VMs are facing this exact issue to be able to better diagnose the problem and it needs to actually be confirmed as being widespread.
@reisenpai said: Ms goes offline from time to time, but it's always at 08:00 PST. All we need to do is manually booting it in the panel.
Who is we? I need to know exactly what list of VMs are facing this exact issue to be able to better diagnose the problem and it needs to actually be confirmed as being widespread.
Personally, I am not seeing this. My 2.5GB VPS on Node 39 has not gone down and needed to be rebooted from the panel at all since activation. My 1.5GB VPS on Node 39 has not gone down and stayed down before today at 5:56AM PDT. I have not been able to check why this went down because of the SolusVm issues, but I do not expect it to be related to the issue others are talking about.
@reisenpai said: Ms goes offline from time to time, but it's always at 08:00 PST. All we need to do is manually booting it in the panel.
Who is we? I need to know exactly what list of VMs are facing this exact issue to be able to better diagnose the problem and it needs to actually be confirmed as being widespread.
Besides the guy replied to this thread, it's all on OGF. I don't want go back there so you gotta check it yourself.
Edit:
And at p70, quote from me: "Alma seems to be alright so far, you might need manually boot it in the panel whenever it goes off."
I think this is the first time anybody talked about unexpected offline.
@reisenpai said: Ms goes offline from time to time, but it's always at 08:00 PST. All we need to do is manually booting it in the panel.
Who is we? I need to know exactly what list of VMs are facing this exact issue to be able to better diagnose the problem and it needs to actually be confirmed as being widespread.
Besides the guy replied to this thread, it's all on OGF. I don't want go back there so you gotta check it yourself.
@VirMach said: I wouldn't be able to help anyone here until SolusVM comes back online but I can assure you that the node is online and also not running into the same disk issues it did in the past.
Is there any chance for Buffalo to move to Japan now?
Comments
Hahahaha....
I only have 3 in virmach, the others I have more at other service providers (gxxx, axx, rxxx, bxx)
Never experienced anything strange like this, before I requested according to hostnane and was not responded to, are you a virmach employee?
In my 2 vps, virmach ColorCrossing, once requested rDNS to my hostname and returned it to IP, there is no such slow process.
Nope.
Can't tell exactly, 'cos I can't login but have about 12 active VPS of which about 9 are actually utilised. I always match rDNS on servers that are being used. It used to be a manual Ticket process, though now it's pseudo automated from a button in the Client Area (which creates a Ticket).
It wisnae me! A big boy done it and ran away.
NVMe2G for life! until death (the end is nigh)
That's strange, why in my previous 2 vps, it was enough to go through the existing menu and the process didn't take long time and only took half a day. on this new ryzen vps, I asked through the menu and waited 10 days it didn't change to the hostname, I decided to send a manual ticket and asked to return it to the IP, but the result is the same. I'm confused.
ryzen is still in beta stage
I bench YABS 24/7/365 unless it's a leap year.
ohh, thanks for the information, if there is information like this from virmach then it will be clear. so I don't expect anything else to be a misperception. thanks for the explanation.
@VirMach is writing ....
LES • About • Donate • Rules • Support
Is there a way to get a console for a system when billing.virmach.com isn't responding that doesn't require me to have thought ahead and written down the link for that specific server?
In my understanding, no.
EDIT:
Except in the activation email under
Advanced Control Panel
If you would like to access your control panel independently, you can use the direct link. Your username is "thisisyourusername" and you must reset your password to obtain it.
LES • About • Donate • Rules • Support
Didn't think so. Thank you, sir.
And we got scheduled reboot/shutdown on 039 again. This time, we can't even boot it manually.
Can you issue a boot up for everyone on 039?
If you're speaking of rDNS on Ryzen, you can assume long waits and potentially for the request to not be filled for now. None of the systems are built for that yet. With CC, we coded it out using their API. We do not consider rDNS critical and those tickets will most likely not be answered until we clear out the entire ticket queue.
Some guy made like 11 tickets for the same rDNS and I'm going to make sure we answer his absolutely last.
Where are you getting your information? You mentioned [A] a scheduled shutdown, [B] everyone being affected on that node.
If I am correct users on Node39, which was a beta test node, are being migrated to a different node.
EDIT: This was misinformation.
As I misunderstood what this comment was referring to:
LES • About • Donate • Rules • Support
There are a few different reasons for that breaking but most recently it would make sense that it's affected by all the attacks.
Nothing scheduled like that and the node is up. I get a lot of reports by a lot of people that that node keeps going down and it's just been up the whole time, I have no idea why people are saying all these things honestly. I guess because it was called beta test node or reported as having issues at some point in time everyone immediately assumes that as the default explanation for everything related to their VPS going offline or even SolusVM running into issues?
Anyway, my guess is that the "we can't even boot it manually" part is related to the fact that SolusVM is down.
Mine is also on 039 node and it’s suddenly down a while ago after 1 day stable.
Here is the metric:
https://tz.115.al/Detail/BEEEE74D
I wouldn't be able to help anyone here until SolusVM comes back online but I can assure you that the node is online and also not running into the same disk issues it did in the past. It's possible that something else went wrong with the node, but not likely. I'd guess something went wrong within the VM and now since SolusVM is broken it's not possible to boot it back up from your end.
Still working hard to get SolusVM back up.
The billing area should be working fine, I think it's just not connecting to SolusVM since that's down, and it may cause it to throw errors or not load your service page.
It actually became fully automated, we just kept it pseudo automated looking on the customer's end. It also helps us use it as a sort of visible log and step in if the system breaks.
But it's not automated at all for Ryzen.
(edit) It's very likely that for Ryzen, we'll just finally enable the actual automated feature on SolusVM. But with it we may also do default port 25 blocks, that can be removed either for a fee or for trusted customers.
IPv6 rDNS!
Haven't bought a single service in VirMach Great Ryzen 2022 - 2023 Flash Sale.
https://lowendspirit.com/uploads/editor/gi/ippw0lcmqowk.png
Edit:
When I says offline or shutdown or reboot, I'm talking about the VM, not the node.
Whenever I reboot the VM within the OS, there is a fair chance for it to go offline until manually booted in the panel.
The reason I said automated or scheduled shutdown is the fact this always happens on 08:00 PST.
I know the node itself is running alright, it's the VMs being offline.
People mistakenly reported it as Node being down because they didn't realize they can just boot the VM up.
Edit: grammar
And I highly doubt it's a problem within the VM, multiple people with different templates and ISO are having the same thing.
Edit:
And just to be clear, we have two problems:
1. VMs goes offline from time to time, but it's always at 08:00 PST. All we need to do is manually booting it in the panel.
2. Whenever we reboot the VMs within OS, there is a chance for it to go offline. And we boot it in the panel.
Yeah, not a huge deal. I rebooted an idler today and forgot it doesn't have automatic encryption unlock yet. I'll take care of it when they give up.
Who is we? I need to know exactly what list of VMs are facing this exact issue to be able to better diagnose the problem and it needs to actually be confirmed as being widespread.
Sounds like a scheduled job killing your server
https://clients.mrvm.net
Personally, I am not seeing this. My 2.5GB VPS on Node 39 has not gone down and needed to be rebooted from the panel at all since activation. My 1.5GB VPS on Node 39 has not gone down and stayed down before today at 5:56AM PDT. I have not been able to check why this went down because of the SolusVm issues, but I do not expect it to be related to the issue others are talking about.
LES • About • Donate • Rules • Support
Besides the guy replied to this thread, it's all on OGF. I don't want go back there so you gotta check it yourself.
At page 76 people are starting to talk about it.
https://lowendtalk.com/discussion/177704/virmach-ryzen-nvme-8-88-yr-384mb-21-85-yr-2-5gb-instant-japan-pre-order-more/p76
Edit:
And at p70, quote from me: "Alma seems to be alright so far, you might need manually boot it in the panel whenever it goes off."
I think this is the first time anybody talked about unexpected offline.
btw mine would be id=652752
IPv6 rDNS should be delegated to a name server specified by the customer.
Only allowing updates may not enough.
See what you can do with IPv6 rDNS delegation:
https://devpost.com/software/traceart-8gsn5o
https://yoursunny.com/t/2016/HackArizona/
Webhosting24 aff best VPS; ServerFactory aff best VDS; Cloudie best ASN; Huel aff best brotein.
Is there any chance for Buffalo to move to Japan now?