VirMach - Complain - Moan - Praise - Chit Chat

1172173175177178317

Comments

  • VirMachVirMach Hosting Provider
    edited August 2023

    @yoursunny said:

    @VirMach said:

    @tomsm said:
    ny 022 is not work Offline PhysicalValuable-VM id:688689

    Click on also can not be normal

    This is the #1 issue and #1 reason we get tickets recently. People have an old ISO mounted, probably forget about it, after it gets rebooted a long time later, especially if we updated the ISO since then, SolusVM will not unmount it automatically and instead completely refuses to boot the VM back online without providing proper error on clientside.

    I made a knowledgebase article for it already but all you need to know is you have to unmount ISO and then boot.

    Make script to automatically unmount ISO after 48 hours.

    Should've just listened to you. We made a script tied to the reboot button that unmounts and also added a note when boot button is used. It turns out people who don't unmount ISO also don't use the reset button or read before making a ticket.

    Thanked by (1)FrankZ
  • VirMachVirMach Hosting Provider
    edited August 2023

    @somik said: Well, in his defense, he is not wrong. You should have a way to find tickets older then X days and prioritize them OR reply to them OR some way to let them know what to do.

    His ticket was definitely in the queue, and skipped on purpose. He already knew he used the IPv6 button twice. We're not going to focus on prioritizing answering tickets that request urgent IPv6. Because once it's answered it's guaranteed to turn into an argument or another ticket being created if someone is already resorting to ignoring any procedure. In fact I'm pretty sure something like that already occurred so he was marked accordingly. This helps us get to the right tickets on time.

    His ticket did also receive an AI response that correctly told him we don't officially offer IPv6, IIRC. If an AI can find this information because you didn't even type in "IPv6" into the knowledgebase then the ticket is not guaranteed to receive any further response, especially on a custom ticket.

    @somik said: OR charge them PER ticket opened/replied. Basically some way to reduce the number of tickets pending replies for over X days.

    Customers have the option to purchase the correct support level if they want responses to everything, even if it's in the knowledgebase and we'll go over everything with them. So your suggestion is already effectively implemented if that's the level of support someone requires.

    Thanked by (2)FrankZ somik
  • VirMachVirMach Hosting Provider

    Oh also I didn't really announce this but this is pretty cool, everyone should know it exists now. We hooked up our helpdesk chat bot on the website to GPT as well, and it will be extremely helpful in answering questions for you if you're just quickly trying to have a policy or content in a knowledgebase article or information our website presented to you. Even works pretty well for being able to quickly figure things out for your operating system although for that you can just use ChatGPT directly.

    Some examples, these are from tickets I reviewed/answered today, which it answered correctly for those most common situations that the customers were facing.

  • @VirMach said:

    @yoursunny said:

    @VirMach said:

    @tomsm said:
    ny 022 is not work Offline PhysicalValuable-VM id:688689

    Click on also can not be normal

    This is the #1 issue and #1 reason we get tickets recently. People have an old ISO mounted, probably forget about it, after it gets rebooted a long time later, especially if we updated the ISO since then, SolusVM will not unmount it automatically and instead completely refuses to boot the VM back online without providing proper error on clientside.

    I made a knowledgebase article for it already but all you need to know is you have to unmount ISO and then boot.

    Make script to automatically unmount ISO after 48 hours.

    Should've just listened to you. We made a script tied to the reboot button that unmounts and also added a note when boot button is used. It turns out people who don't unmount ISO also don't use the reset button or read before making a ticket.

    Disallow opening tickets until 12 hours after (1) the reset button has been pressed and (2) VNC connection has been established and lasted at minimum of 300 seconds.

    HostBrr aff best VPS; VirmAche aff worst VPS.
    Unable to push-up due to shoulder injury 😣

  • @yoursunny said:

    @VirMach said:

    @yoursunny said:

    @VirMach said:

    @tomsm said:
    ny 022 is not work Offline PhysicalValuable-VM id:688689

    Click on also can not be normal

    This is the #1 issue and #1 reason we get tickets recently. People have an old ISO mounted, probably forget about it, after it gets rebooted a long time later, especially if we updated the ISO since then, SolusVM will not unmount it automatically and instead completely refuses to boot the VM back online without providing proper error on clientside.

    I made a knowledgebase article for it already but all you need to know is you have to unmount ISO and then boot.

    Make script to automatically unmount ISO after 48 hours.

    Should've just listened to you. We made a script tied to the reboot button that unmounts and also added a note when boot button is used. It turns out people who don't unmount ISO also don't use the reset button or read before making a ticket.

    Disallow opening tickets until 12 hours after (1) the reset button has been pressed and (2) VNC connection has been established and lasted at minimum of 300 seconds.

    That's just stupid. If a VPS isn't working, people will first try to reset it, followed by opening a support ticket. Since they already have bots replying to the tickets, it makes more sense to just feed the bot answers to "VPS not working" questions with unmount ISO and such.

    Websites have ads, I have ad-blocker.

  • @VirMach said:

    @yoursunny said:

    @VirMach said:

    @tomsm said:
    ny 022 is not work Offline PhysicalValuable-VM id:688689

    Click on also can not be normal

    This is the #1 issue and #1 reason we get tickets recently. People have an old ISO mounted, probably forget about it, after it gets rebooted a long time later, especially if we updated the ISO since then, SolusVM will not unmount it automatically and instead completely refuses to boot the VM back online without providing proper error on clientside.

    I made a knowledgebase article for it already but all you need to know is you have to unmount ISO and then boot.

    Make script to automatically unmount ISO after 48 hours.

    Should've just listened to you. We made a script tied to the reboot button that unmounts and also added a note when boot button is used. It turns out people who don't unmount ISO also don't use the reset button or read before making a ticket.

    Wont that cause issues with people using Alpine linux which requires the ISO to boot if you use their minimal installation?

    Websites have ads, I have ad-blocker.

  • @somik said:

    @VirMach said:

    @yoursunny said:

    @VirMach said:

    @tomsm said:
    ny 022 is not work Offline PhysicalValuable-VM id:688689

    Click on also can not be normal

    This is the #1 issue and #1 reason we get tickets recently. People have an old ISO mounted, probably forget about it, after it gets rebooted a long time later, especially if we updated the ISO since then, SolusVM will not unmount it automatically and instead completely refuses to boot the VM back online without providing proper error on clientside.

    I made a knowledgebase article for it already but all you need to know is you have to unmount ISO and then boot.

    Make script to automatically unmount ISO after 48 hours.

    Should've just listened to you. We made a script tied to the reboot button that unmounts and also added a note when boot button is used. It turns out people who don't unmount ISO also don't use the reset button or read before making a ticket.

    Wont that cause issues with people using Alpine linux which requires the ISO to boot if you use their minimal installation?

    Anybody running Alpine will have enough clues to figure it out on their own. That's not this crew.

    Thanked by (2)yoursunny Wonder_Woman
  • @skorous said:

    @somik said:
    Wont that cause issues with people using Alpine linux which requires the ISO to boot if you use their minimal installation?

    Anybody running Alpine will have enough clues to figure it out on their own. That's not this crew.

    True. And they can just do the full installation and boot from disk, even though that will lower their disk space.

    Websites have ads, I have ad-blocker.

  • Reason for Outage
    Date: July 31, 2023

    Summary:
    This document serves as the Reason for Outage (RFO) to provide a comprehensive explanation of the network interruption that occurred on July 28th, 2023. The purpose of this RFO is to outline the root cause, impact, actions taken for resolution, and preventative measures to avoid similar incidents in the future.

    Incident Overview:
    On July 28th, 2023, at approx. 6PM EST a network interruption was experienced in San Jose, Redondo Beach, and Secaucus. This interruption resulted in a partial or complete loss of network connectivity and services for affected services. The incident was resolved at on July 28th, 2023 approx. 8:25PM with the exception of customers that were affected by a switch failure in Secaucus.

    Root Cause Analysis:
    After a thorough investigation, the root cause of the network interruption has been identified as follows:

    Issue with common upstream provider we have in all three locations.

    An unrelated switch failure that occurred in Secaucus, which affected a small portion of customer in New Jersey.

    Impact:
    The network interruption had the following significant impact:

    Downtime: Affected systems experienced a loss of connectivity, leading to disruptions in services.

    Actions Taken:
    Upon identifying the root cause, the following actions were taken to resolve the network interruption:

    Immediate Notification to Upstream Provider: The network team promptly contacted upstream providers to resolve the upstream issue.

    Testing and Verification: After the upstream provider implemented the fix, DediPath performed thorough testing and verification were performed to ensure the stability and functionality of the network.

    Since the incident was resolved we have opened discussions with other providers to prevent this situation from occurring again.

    Conclusion:
    The network interruption experienced on July 28th was a significant incident that impacted the organization and its users. Through a comprehensive root cause analysis and implementation of preventative measures, we aim to strengthen the network's resilience and provide a more robust and reliable service to our customers. We apologize for any inconvenience caused and remain committed to continually improving our network infrastructure.

    If you have any further questions or concerns, please do not hesitate to reach out to our support team at [email protected]

    Sincerely,

    DediPath

  • Just wanted to give a shout out to Virmach.
    After almost 6 months, I have finally gotten my Stromonic Refugee VPS (NVMe 1G), that too in Tokyo.

    Since my Stromonic VPS billing had expired in June, I was expecting just a price match at this point of time - but Virmach has included some free months in the plan!

    Thanks again, @VirMach !

  • @lesuser said:
    Reason for Outage
    Date: July 31, 2023

    Summary:
    This document serves as the Reason for Outage (RFO) to provide a comprehensive explanation of the network interruption that occurred on July 28th, 2023. The purpose of this RFO is to outline the root cause, impact, actions taken for resolution, and preventative measures to avoid similar incidents in the future.

    Incident Overview:
    On July 28th, 2023, at approx. 6PM EST a network interruption was experienced in San Jose, Redondo Beach, and Secaucus. This interruption resulted in a partial or complete loss of network connectivity and services for affected services. The incident was resolved at on July 28th, 2023 approx. 8:25PM with the exception of customers that were affected by a switch failure in Secaucus.

    Root Cause Analysis:
    After a thorough investigation, the root cause of the network interruption has been identified as follows:

    Issue with common upstream provider we have in all three locations.

    An unrelated switch failure that occurred in Secaucus, which affected a small portion of customer in New Jersey.

    Impact:
    The network interruption had the following significant impact:

    Downtime: Affected systems experienced a loss of connectivity, leading to disruptions in services.

    Actions Taken:
    Upon identifying the root cause, the following actions were taken to resolve the network interruption:

    Immediate Notification to Upstream Provider: The network team promptly contacted upstream providers to resolve the upstream issue.

    Testing and Verification: After the upstream provider implemented the fix, DediPath performed thorough testing and verification were performed to ensure the stability and functionality of the network.

    Since the incident was resolved we have opened discussions with other providers to prevent this situation from occurring again.

    Conclusion:
    The network interruption experienced on July 28th was a significant incident that impacted the organization and its users. Through a comprehensive root cause analysis and implementation of preventative measures, we aim to strengthen the network's resilience and provide a more robust and reliable service to our customers. We apologize for any inconvenience caused and remain committed to continually improving our network infrastructure.

    If you have any further questions or concerns, please do not hesitate to reach out to our support team at [email protected]

    Sincerely,

    DediPath

    I don't get it. this is a whole long yadayada that means nothing. i hate 'corporate speak'

    Fuck this 24/7 internet spew of trivia and celebrity bullshit.

  • @Encoders said: I don't get it. this is a whole long yadayada that means nothing. i hate 'corporate speak'

    They admitted they had a problem, explained the problem and are saying they are committed to trying to prevent these types of things in the future, what more did you want?

    Thanked by (2)AlwaysSkint someTom
  • AdvinAdvin Hosting Provider

    @JoeMerit said:

    @Encoders said: I don't get it. this is a whole long yadayada that means nothing. i hate 'corporate speak'

    They admitted they had a problem, explained the problem and are saying they are committed to trying to prevent these types of things in the future, what more did you want?

    The reason for the outage, which the RFO doesn't really answer.

    I am a representative of Advin Servers

  • edited August 2023

    @Advin said: which the RFO doesn't really answer.

    @lesuser said: [Quoting Dedipath] Issue with common upstream provider we have in all three locations.
    An unrelated switch failure that occurred in Secaucus, which affected a small portion of customer in New Jersey.

    (I recognise that the language may be hard for some and it isn't exactly brimming with information.)

    It wisnae me! A big boy done it and ran away.
    NVMe2G for life! until death (the end is nigh)

  • @JoeMerit said:

    @Encoders said: I don't get it. this is a whole long yadayada that means nothing. i hate 'corporate speak'

    They admitted they had a problem, explained the problem and are saying they are committed to trying to prevent these types of things in the future, what more did you want?

    Well they took a page and a half to say, "Our upstream messed up. We called them. They fixed it." but never what it was nor how they're going to try to make it not happen again only that they're having "discussions with other providers".

    Thanked by (1)Not_Oles
  • edited August 2023

    ^ Agreed, regards the what but to be fair, they can't really elaborate, on [any?] discussions with other providers.

    It wisnae me! A big boy done it and ran away.
    NVMe2G for life! until death (the end is nigh)

  • @AlwaysSkint said:
    ^ Agreed, regards the what but to be fair, they can't really elaborate, on [any?] discussions with other providers.

    If they'd told us the "what" those discussions might not be as important to know since if it was a technical issue then they'd be able to discuss it.....

    Thanked by (1)Not_Oles
  • NeoonNeoon OG
    edited August 2023

    Logged in, since I was on the hunt for an idle machine.
    The new Panel, haaayaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

    The CSS was bugging through the footer.

    Thanked by (1)ariq01
  • NYCB028 - Operation Timed Out After 90000 Milliseconds With 0 Bytes Received

  • edited August 2023

    @julensm said:
    NYCB028 - Operation Timed Out After 90000 Milliseconds With 0 Bytes Received

    NYCB028 is up for me. Last outage was reported in July 28.
    Or that's just control panel issue not actual server outage report?

    Thanked by (1)FrankZ
  • my NY vps is down AGAIN. I can't ssh. I can't open my service page in virmach dashboard. I can't reboot, I can't do a damn thing
    what an agony it's been with you guys...

  • What node?

  • I don't have the node number. I can't access my service page...

  • FrankZFrankZ Moderator

    @cyforex - NYCB043 is down, NYCB028 is overloading. Does ether of these sound familiar ?

    Thanked by (1)lesuser

    I am currently traveling in mostly remote areas until sometime in April 2024. Consequently DM's sent to me will go unanswered during this time.
    For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add

  • @FrankZ said:
    @cyforex - NYCB043 is down, NYCB028 is overloading. Does ether of these sound familiar ?

    yes it is NYCB028.
    I was able to open my service page for a minute, it's down again though.

  • FrankZFrankZ Moderator

    @cyforex said:

    @FrankZ said:
    @cyforex - NYCB043 is down, NYCB028 is overloading. Does ether of these sound familiar ?

    yes it is NYCB028.
    I was able to open my service page for a minute, it's down again though.

    Should be better now.

    I am currently traveling in mostly remote areas until sometime in April 2024. Consequently DM's sent to me will go unanswered during this time.
    For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add

  • NYCB027 has been unavailable for over 100 days. New record?

    Thanked by (1)Flying_Chinaman
  • FrankZFrankZ Moderator

    Thanked by (1)localhost

    I am currently traveling in mostly remote areas until sometime in April 2024. Consequently DM's sent to me will go unanswered during this time.
    For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add

  • edited August 2023

    ↑↑↑↑↑↑

    Wrong vehicle above, here it goes the correct one

    smartass shitposting satirist

  • @FrankZ said:
    @cyforex - NYCB043 is down, NYCB028 is overloading. Does ether of these sound familiar ?

    Yeah cannot access NYCB043 on https://billing.virmach.com although VPS is working fine.

Sign In or Register to comment.