Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
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.

★ VirMach ★ RYZEN ★ NVMe ★★ $8.88/YR- 384MB ★★ $21.85/YR- 2.5GB ★ Instant ★ Japan Pre-order ★ & More

1124125127129130339

Comments

  • Is there a pre-sale program for Hong Kong VPS?

  • bdlbdl Member

    @xposedcat said:
    Is there a pre-sale program for Hong Kong VPS?

    I think we'll be lucky to see ANY future pre-sales considering the behaviour of some customers during this pre-sale :p

  • VirMachVirMach Member, Patron Provider

    @ehab here you go.
    https://virmach.com/ryzen-special-offer-news-updates/

    I'll add more information later, about storage plans, etc. Let me know if anyone recommends adding anything else here.

  • yufanyufan Member

    @yufan said:
    My Tokyo service has been activated. The next due date of the service is still 03 / 12 / 2023. I post this problem in the thread last time. But still, maybe I've been forgotten. :'( Could you please fix it for me alone. My invoice ID #1397135.

    @VirMach please check this problem.

  • VirMachVirMach Member, Patron Provider

    @yufan said:

    @yufan said:
    My Tokyo service has been activated. The next due date of the service is still 03 / 12 / 2023. I post this problem in the thread last time. But still, maybe I've been forgotten. :'( Could you please fix it for me alone. My invoice ID #1397135.

    @VirMach please check this problem.

    We'll go through these again soon and change it. Once the sale is over for some time, if you still need help then you can contact us then.

  • VirMachVirMach Member, Patron Provider

    @xposedcat said:
    Is there a pre-sale program for Hong Kong VPS?

    We're not doing Hong Kong at this time, we changed our mind on that location.

    This isn't an "excuse" or "blaming customers" or whatever else negative people are going to call it but unfortunately this did have an effect on that decision, as @bdl mentioned.

    @bdl said:

    @xposedcat said:
    Is there a pre-sale program for Hong Kong VPS?

    I think we'll be lucky to see ANY future pre-sales considering the behaviour of some customers during this pre-sale :p

  • VirMachVirMach Member, Patron Provider

    @vhhjkgl said:

    @Martachjbvguknv said:
    The network of TYOC040 is broken again.
    I ping gateway from my server, and it return
    about 300±200ms.

    virmach checked the Node40 and still did not find the cause of the problem。

    The cause is already found.

    Now we're still working on the permanent fix. I'm trying to avoid doing what you or someone else previously suggested which is just abandoning the node. It's not that the node has any problems, but it's possible that the fix may take longer than just moving everyone to another node. I'm still evaluating.

  • yufanyufan Member
    edited April 2022

    @VirMach said:

    @yufan said:

    @yufan said:
    My Tokyo service has been activated. The next due date of the service is still 03 / 12 / 2023. I post this problem in the thread last time. But still, maybe I've been forgotten. :'( Could you please fix it for me alone. My invoice ID #1397135.

    @VirMach please check this problem.

    We'll go through these again soon and change it. Once the sale is over for some time, if you still need help then you can contact us then.

    OK understand. Thank you for your reply.
    In fact, this is not a big problem, because I think I will always pay to renew this service. :D
    By the way, I would like to ask about Buffalo migration. I saw many people send tags in this post before. My Buffalo vps is blackfriday special .Can i have a migration? Should I still do it this way now, or should it be in another way?

  • VirMachVirMach Member, Patron Provider

    @ceplavia said:

    @opshk said:

    @Such said:
    Quote:Biennial pre-orders in Tokyo will also receive a guaranteed spot on Gen4/Ryzen 5000 Series processor server and will be activated in the first pre-order batch for that location.
    Shouldn't the Biennial pre-order be activated first?just ask, maybe it's a problem with my translation software

    I am having the same question in my mind, though the servers are not stable in the current stage, it still kind of a promise Virmach made in the first post. Or am I missing anything?

    my biennial 768 still pending lol

    I want to clarify something regarding the biennial plans.

    Some people seem to have a misunderstand that these would 100% be created before everyone else. These were listed as being created on the first "batch" which was the batch of Gen4/5900X servers. Then there were other "batches" of servers, with Gen3 being set up next, and then there's a final batch planned which was the 10Gbit, and any others.

    I could have worded this better. Initially this did mean that these would be created first because we were going to try to save some space on 5900X nodes and create everyone else balanced throughout 5000 AND 3000 series.

    However, we decided to put everyone on 5000 series. So the other "batch" was delayed, since we didn't need to send that out with great urgency.

    This resulted in them being mixed more in the same batch.

    In addition to this, even if we did mean that they would all be created first, unfortunately in that situation that's something that would only delay the creation of ALL the services even more. If they're created together this way with the script, I can assure you that you will receive your service sooner than if we had activated biennial plans manually first because of the WHMCS and SolusVM webserver slowdowns. Loading certain pages on our end are still very slow so it would take 5 to 10 times longer than our script.

  • @yufan said:
    By the way, I would like to ask about Buffalo migration. I saw many people send tags in this post before. Should I still do it this way now, or should it be in another way?

    In my opinion, it was like a joke, but I think many people actually thought it as a real campaign.

    Thanked by 1FrankZ
  • VirMachVirMach Member, Patron Provider
    edited April 2022

    @nightcat said:
    hi all

    What we want is a working vps. I think the others are same as me.
    If vps in beta testing or unusable, migrate to other place or reset the billing date or stop it.

    We start to pay money for vps when it boots, we wish had a good service like in other regions.

    That's all.

    I can do nothing on the Tokyo vps from open to now because It is unusable.

    Btw: I have some virmach servers in other regions. and Virmach has done some great job.

    We will provide credits as requested, once it does fully function. You can make a billing ticket, explain the issue, how long it existed, and we'll calculate that and add store credit. But please only do this later, after the issue has already been resolved.

    We are honoring all migration requests to Tokyo if they're clearly stated in a ticket. We recommend making a "priority" ticket for these. You will not be billed $15, as long as the title clearly states you want to temporarily move from Tokyo to San Jose. We'll migrate you and then later on you can reply back on the same ticket and move back for free as well.

    We had to pause these for now because of migration issues but I'm working on that soon.

    Thanked by 1FrankZ
  • VirMachVirMach Member, Patron Provider

    @Such said:

    @VirMach said:

    @ucpaopao said:
    I have no ill will towards virmach
    It could also be that my machine translation didn't convey exactly what I meant
    I would like to be able to purchase virmach merchandise and have patiently wait until today to post some comments
    Sufficient to demonstrate our support, recognition, and inclusive understanding of virmach
    But it seems that this becomes a choice we have to make, not a voluntary expression of personal emotion
    Gives a feeling of being forced, we have to do it,
    Even basic politeness is that we need to respect others, not that we respect each other

    I do believe everything you have said where we disagree is related to how the words are interpreted. A lot of sayings, especially if I speak more informally for estimates, may come across incorrectly and vice versa.

    • Handling/Shipping was originally listed as "maybe" up to 2 weeks. It was delayed but I changed the shipping from 9 day to 1-3 day shipping instead to make it faster.
    • We still stated that datacenter hands still has to receive the equipment after this time and set it up, which we stated was in addition to the previous estimate.
    • We stated that activations would begin at this point, and we did not say when it would complete in our estimates.

    Realistically, this could mean 2 weeks plus 1 week for datacenter hands. I did not state how long datacenter hands would take because I do not know but 1 week is probably the "average" so far for all our locations for the datacenter to put the servers in the cabinet and set everything up. Then we still have to do all the steps that come after "Handling/Shipping" which were listed and are:

    • Provisioning
    • Awaiting IPv4
    • Available

    Then even when it is available, it was still listed as "usually instant" so obviously in a case where one location outsold all the others to an extreme degree, there will only be so many of them that can activate at once. All those estimates, and again, they are only guesses, were based on the information we knew that day. We did not know how many of each plan would go where, only how many total we were selling across all locations.

    We did know Tokyo would be a little bit more popular, but honestly, I assumed a lot more people would go for the "instant" locations.

    We also made sure to have "instant" locations before we posted the sale to try to avoid this situation where people are dissatisfied. That way they had two options depending on if they wanted to wait or not. Even at any point in time, if people do not want to wait for a pre-order, we still have been processing refunds every few days if it's requested.

    In the end, our estimate was very close to when we actually began deploying services, but the rollout after that has been slower than what I expected. We are still at over 50% deployed in Tokyo in 4 weeks, and that's with shipping issues, hardware/firmware issues, 1-2 days of DDoS attack, and more.

    Maybe I am biased but I would say we made it out pretty good.

    Quote:Biennial pre-orders in Tokyo will also receive a guaranteed spot on Gen4/Ryzen 5000 Series processor server and will be activated in the first pre-order batch for that location.
    Shouldn't the Biennial pre-order be activated first?just ask, maybe it's a problem with my translation software

    I clarified this above. I don't want to start an argument about it though, so again, even if it is the way you mentioned, which is plausible as I agree I could have explained it better, it would still be the same end result.

    Initially when I explained it, there was no difference between the way I said it and the way you said it, but because the way batches were sent out got changed, they all ended up on the first batch of 5900X/Gen4 servers.

  • VirMachVirMach Member, Patron Provider

    @leendon said:

    @VirMach said:

    @vhhjkgl said:

    @tototo said:

    @vhhjkgl said:
    I found a strange appearance, first I installed Centos7 and then went to DD's debian11, Centos7's data was not cleared at all, but the latency became abnormally stable.Node40

    First install CENTOS7, then install bebian11 is unable to eliminate centos7 date, ssh connection still shows Centos7 information. I've tried a few times.

    I have some questions.
    What is "DD's Debian"? Is overwriting installed disk image (an image of a gz or xz compressed system disk instead of an ISO) to /dev/vda using the dd command?
    I've heard it's a bit popular in China, but I don't think it's very common.
    Also, if the overwrite by dd was successful, the CentOS data should have lost, so I think you failed in dd.
    To me, the machine has rebooted, so it's stable.

    When the cpu load is very low, the latency is low and stable, but when I enable the proxy and the cpu load increases, a slight increase causes huge fluctuations in latency, which is not normal . Further, when I have other operations, the latency becomes huge whenever there is a slight change in CPU, which I have tried many times.

    I'm looking into TYOC040 again right now. I may check your VPS out in the next hour, just letting you know.

    How long does it take to activate the storage type?

    I'll have an update on these later.

    Thanked by 1FrankZ
  • VirMachVirMach Member, Patron Provider

    @vhhjkgl said:

    @VirMach said:

    @vhhjkgl said:

    @tototo said:

    @vhhjkgl said:
    I found a strange appearance, first I installed Centos7 and then went to DD's debian11, Centos7's data was not cleared at all, but the latency became abnormally stable.Node40

    First install CENTOS7, then install bebian11 is unable to eliminate centos7 date, ssh connection still shows Centos7 information. I've tried a few times.

    I have some questions.
    What is "DD's Debian"? Is overwriting installed disk image (an image of a gz or xz compressed system disk instead of an ISO) to /dev/vda using the dd command?
    I've heard it's a bit popular in China, but I don't think it's very common.
    Also, if the overwrite by dd was successful, the CentOS data should have lost, so I think you failed in dd.
    To me, the machine has rebooted, so it's stable.

    When the cpu load is very low, the latency is low and stable, but when I enable the proxy and the cpu load increases, a slight increase causes huge fluctuations in latency, which is not normal . Further, when I have other operations, the latency becomes huge whenever there is a slight change in CPU, which I have tried many times.

    I'm looking into TYOC040 again right now. I may check your VPS out in the next hour, just letting you know.

    You can do anything. I'll rebuild it after restoring normal use

    I did work on this when I said I would, I just didn't get to looking at yours specifically. I skipped it for now as it doesn't seem to be overloading or wasn't overloading when I last was working on it.

  • yufanyufan Member

    @tototo said:

    @yufan said:
    By the way, I would like to ask about Buffalo migration. I saw many people send tags in this post before. Should I still do it this way now, or should it be in another way?

    In my opinion, it was like a joke, but I think many people actually thought it as a real campaign.

    :'( oh. Thanks for explaining.

  • VirMachVirMach Member, Patron Provider

    TYOC040 Update - just adding a small note/update here, to rule out this being caused by the switch or network cable or the way it is seated, we requested some time ago that the datacenter replace the cable. This has been completed.

    We've had some very rare cases where something similar was alleviated to some degree when the cable was changed. We didn't expect this to actually work or be the solution, but it was just done as a precaution.

    Thanked by 2FAT32 FrankZ
  • VirMachVirMach Member, Patron Provider
    edited April 2022

    @tototo said:

    @yufan said:
    By the way, I would like to ask about Buffalo migration. I saw many people send tags in this post before. Should I still do it this way now, or should it be in another way?

    In my opinion, it was like a joke, but I think many people actually thought it as a real campaign.

    It wasn't a joke, I just never posted the offer that was going to have it, because I already had too much to deal with and didn't want to spend the next 3 weeks manually updating everyone's orders and manually migrating them for a tongue-in-cheek meme campaign inside a second sale here.

    (edit) Well it was a joke but the joke was that it was actually real. The joke is that we'd get unlimited bumps from it since everyone hates Buffalo.

  • @VirMach said:
    TYOC040 Update - just adding a small note/update here, to rule out this being caused by the switch or network cable or the way it is seated, we requested some time ago that the datacenter replace the cable. This has been completed.

    We've had some very rare cases where something similar was alleviated to some degree when the cable was changed. We didn't expect this to actually work or be the solution, but it was just done as a precaution.

    Don’t forget 039 node which is not as stable as yesterday, maybe the similar situation with 040

    Thanked by 1dudu
  • I quickly read through the entire 127 pages of the thread and was very surprised that the content rose to the level of racism. Personally, I don't think it's necessary to be in such a hurry to argue whether it's a racist act or not, I've bought many VPS from both LET TOP Provider and IDC Provider run by Chinese people themselves, and I'd like to give some insights.

    In fact, people have different definitions and expectations of "pre-sales", for example, I couldn't understand some of the practices of some of the members from LET earlier - from my personal point of view, I think I might be more concerned about the logistics of the news For example, the news that a certain machine has been successfully cleared in Tokyo, Japan, and that the machine has been tested on the cabinets, etc. I didn't realize until later that our perceptions seemed to be different in many cases.

    In fact, many people are not willing to endlessly rush providers, but the actions of some junk merchants have thoroughly disappointed them, and since then may be less willing to accept situations where the service is clearly up and running, but the network quality is so bad that it doesn't work. As you can see, there was once a provider called PacificRack, which broke the perception of cheap low-end VPS with its super lousy technical service level and super lousy customer service. People used to give it too much expectation, too much confidence and patience, and what they got in return was endless high packet loss and data loss.

    Now that I've read more threads, I've been able to know more about what more players on LET want to discuss (technology first, discussing difficulties and challenges, not caring so much about when the service will be available) but this may bring some misunderstandings, because in fact, since English is not our native language, many of us are willing to use various translations hoping to communicate with you, however However, because of the very different inner thoughts and attitudes about expectations and about pre-orders, it is easy to cause too many misunderstandings and cause some completely unnecessary conflicts.

    In the habits of Chinese providers, "testing" usually means that everything is ready, the system templates have been installed, multiple VPS have been opened and working steadily for several days (yes, in the program version, it means Beta), even if there are some minor problems, it should not be catastrophic, usually within 10 days you can The full pre-sales service is open. Virmach's "test" seems to be more like the "Early Access"/Alpha of the Steam game, where the system template is not completely prepared, but only an experimental installation of the KVM virtualization is controlled software, but what happens after installation is unknown and can lead to serious bugs. (Yes, because few Chinese providers make their experimental EA publicly available, these are tested by the providers themselves, and many people are not particularly clear about the difference)

    With more and more prodding, Virmach seems to be a bit too eager as more and more people are finding out that early EA's are underperforming and their service is still not up and running and opting for refunds. So it started to open some services on a large scale, only to have more problems show up and a sea of work orders pour in because of the lack of early preparation, which doesn't seem to cheer anyone up anyhow.

    I have Virmach upstream provider xTom's VPS, and both have the exact same network, so I also didn't pay much attention to this thread before, until I realized that this thread has a whole 127 pages of content and has gone completely off the right track, so I thought I should talk a little bit about my own humble opinion, and hope it will be helpful to all of you. Please correct me if there are any errors.

    Thanks :smile:

  • ehabehab Member

    thanks a lot.

    now should be easier for all to follow.

    It can be used for any who created a ticket to ask.

    best wish to you and the virmach team.

    Thanked by 1bdl
  • cybertechcybertech Member
    edited April 2022

    suggest to rank

    Available > Provisioning > Deploying > Shipping

    if this will take more than a month for all equipment to reach data center hands

    for those whose English is not first language, some pattern helps

  • @cybertech said:
    suggest to rank

    Available > Provisioning > Deploying > Shipping

    if this will take more than a month for all equipment to reach data center hands

    for those whose English is not first language, some pattern helps

    It might be better to have something like "Instant", which is a higher rank than "Available".
    It's all in the notes, but even so, I can't expect people opening nonsense tickets to read it...

  • Invoice 1413925 When is it available please

  • @tototo said:

    @cybertech said:
    suggest to rank

    Available > Provisioning > Deploying > Shipping

    if this will take more than a month for all equipment to reach data center hands

    for those whose English is not first language, some pattern helps

    It might be better to have something like "Instant", which is a higher rank than "Available".
    It's all in the notes, but even so, I can't expect people opening nonsense tickets to read it...

    then maybe "Manual Activation" instead of instant,

    Thanked by 1tototo
  • @VirMach said:
    All broken disk services fixed on TYOC033. You just need to re-install the OS.

    After reinstalling the Debian11 system, the status is displayed online, but the VNC shows the following information

    Booting form Hard Disk...
    Boot failed: not a bootable disk

    Booting from DVD/CD...
    Boot failed: Could not read from CDROM (code 0003)
    No bootable device

  • I wish I could move my Tokyo node to TYOC033 or TYOC035...

  • VirMachVirMach Member, Patron Provider

    @sjlleo said: Virmach's "test" seems to be more like the "Early Access"/Alpha of the Steam game, where the system template is not completely prepared, but only an experimental installation of the KVM virtualization is controlled software, but what happens after installation is unknown and can lead to serious bugs.

    This was never intended to be a "test" because we intended the hardware we purchased to work as expected/advertised. It also functioned properly until it was specifically set up with libvirt/qemu and that was the initial issue, which was resolved. Then the disks failed, which is hardware failure and not up to us. We didn't exactly cheap out on these parts either, these were the most expensive NVMe's we purchased because they're supposed to be high performance. It was the only brand we could get with that level of performance in the quantities we required at the time.

    The operating systems issue was listed from the beginning:

    Please note that Ryzen servers may still have some minor issues, such as the web VNC not functioning, or certain ISO or OS templates missing at this time. Please report these issues only on this thread if possible as it will reduce ticket load.

    We didn't develop libvirt/qemu/SolusVM, nor any of the operating systems or SolusVM default templates. Of course, not all of them will work in every situation. Even when these are thoroughly tested, there will always be some use cases especially with older operating systems that run into issues.

    In our near decade in business, there have always been some of these problems. We just did not expect these issues to cause such high level of interrupts, thus affecting networking on these specific nodes with specific kernel version and software versions.

    We've ran multiple nodes before these and they did not have these same problems to this level to where it negatively affected the networking.

    @sjlleo said: With more and more prodding, Virmach seems to be a bit too eager as more and more people are finding out that early EA's are underperforming and their service is still not up and running and opting for refunds.

    This has nothing to do with refunds. Most refunds were already processed before these nodes even went online. As we got closer, less people requested cancellations and refunds because most people are willing to wait.

    So with that said, I'm just wondering, and would like your feedback. How do you imagine this should have been done instead? Should we have only deployed Gen3 servers for Tokyo? The next batch will be Gen3, and if that's the case then we'll allow people to move to those free of charge. As for the issues we faced, do you really not believe they were handled to the best of our ability? We found a patch for a really strange bug with specific hardware/software incompatibility where we do not have access to the firmware. We contacted all the vendors, and their engineers are still working on this and were not even able to independently locate a fix (which we did.) And I do not claim to be an engineer, they do, yet they're falling behind even the first steps we already completed, even with our information/guidance. What would be done in this case? We also quickly already located the interrupt issue and know how to fix it, we are just evaluating how we should proceed, if it would be faster to recreate all these and how we would plan that with customers to avoid any data loss and provide proper notice without further delays, or if it would be faster going through all existing services and mass powering down and contacting those virtual servers affecting the node. We've also offered to migrate these people to existing nodes in San Jose for the time being and this timeline has only been the last few days to a week. We have not added a significant amount of delay compared to the initial communication, and other locations were and still are available for people who do not want to participate in a pre-order product. Nodes in Phoenix were up for weeks to months. Nodes in Seattle, similar. Yet people did not pick these locations that were available and opted to wait for another knowing that it was a pre-order with a timeline in the weeks.

  • VirMachVirMach Member, Patron Provider

    @tototo said:

    @cybertech said:
    suggest to rank

    Available > Provisioning > Deploying > Shipping

    if this will take more than a month for all equipment to reach data center hands

    for those whose English is not first language, some pattern helps

    It might be better to have something like "Instant", which is a higher rank than "Available".
    It's all in the notes, but even so, I can't expect people opening nonsense tickets to read it...

    I want to avoid using the word "instant" for now. I already removed it a while ago from the location selections and tried to avoid using it moving forward. I don't know how well of a job I've done but I don't want people to think that anything will be within 1 second.

    So unfortunately that means it'll be "available" no matter what state of "available" it is in right now. I could add a word beneath that but then all of them would still go into that as they're all available with some minor caveats.

    Thanked by 2tototo FrankZ
  • VirMachVirMach Member, Patron Provider

    @Cheung said:

    @VirMach said:
    All broken disk services fixed on TYOC033. You just need to re-install the OS.

    After reinstalling the Debian11 system, the status is displayed online, but the VNC shows the following information

    Booting form Hard Disk...
    Boot failed: not a bootable disk

    Booting from DVD/CD...
    Boot failed: Could not read from CDROM (code 0003)
    No bootable device

    "Power down" first and then try re-install.

  • VirMachVirMach Member, Patron Provider

    @tototo said:
    I wish I could move my Tokyo node to TYOC033 or TYOC035...

    I'm going to speak to our developer today and see if we can implement our migration without data script to allow people on TYOC040 or TYOC039 to recreate on another random node. That might help everyone, including us, and calm things down.

    I'm setting up two more nodes right now as well.

This discussion has been closed.