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
From other topic:
If you're answering questions - I have one that I'll never be able to submit a ticket about because ISO installation is a possibility:
Why are root passwords non-functional 80% of the time when installing certain Debian KVM templates?
That's it, wonder why nobody else noticed that fact. Still, being compared to something greater is cool advertising already.
This is the funny part about LET IMO. But it has some charm.. Guys share knowledge and they quickly figure out who is who here.
Open a ticket and ask them to enable CPU host passthrough. Then you'll see the real CPU model, and AES-NI will be available for use. The CPU is most likely a Xeon E3 or E5.
Alternatively, I believe the (mostly undocumented) work-around is to install an OS from the template, followed by the ISO install. If you install directly from ISO, the VM doesn't have CPU flags enabled.
The trick is reinstall to templates with "gen2", debian 8 personally.
Then, you can reinstall to any other os you want.
Without this whole 'service not provisioned in time / 9+ day ticket response time' shenanigans, I would choose anyone over VirMach only because of their strict resource limitations.
It's like "Hey, take these 3 cpu cores, BUT ACTUALLY please don't use them, we don't do that here"
Then, you can reinstall to any other os you want.
Thanks for being more specific. I've personally just reinstalled with Debian 9 and that's been fine too.
Honestly, I used to think similarly. I held off on BF 2019 and only picked up 2 services, and they worked well enough at the time that I picked up much more during BF 2020. One of my VMs had 3 cores so I just CPU limited to 1 core and that seemed to work out fine with no complaints from Virmach.
They're perfectly fine for personal use. I don't have any resentment towards Virmach, but I find it super unfortunate when any criticism of Virmach is shut down because Amir threatens not to hold more sales or "my service has been perfect, you're lying". Virmach can't be compared to Vultr, but that doesn't stop people from claiming Virmach is on par with large IaaS providers.
Virmach is certainly not perfect, and holding hosts on a pedestal (thinking they're perfect) is really counter-productive to what a hosting forum should be doing: offering a place to candidly share feedback and advice about hosting.
I understand that Virmach is flooded with tickets. I try and avoid opening them myself unless my service is literally unusuable. I get that it's a low-margin service and that I'm not entitled to open 3 tickets and demand an urgent response for the low prices I'm paying, but support is still very lacking and Virmach is a poor option in any case where you're doing something important/production with your service. Took me days to get an unusable service addressed after "awaiting technical review".
I didn't care that much because it wasn't like I was hosting a web store on it or anything; just doing my thing in the meantime.
It depends on the node you're on and the specific operating system/kernel version. At some point in time SolusVM's functionality broke or some template-related operations. It's on the list to try to get it uniform and re-do these templates that we have direct from SolusVM in a way where it works with the reset features. We did correct most of these already, for example, Debian 9 had this issue and it was resolved, unless a new SolusVM update broke the functionality in some way. We encourage you to report these to us because this is how we can identify and resolve it more quickly for the exact version on the exact node your service is on.
It will always be possible to replicate these buttons to some degree by essentially doing what SolusVM tries to do. If these functions do not work, you can also contact us and as long as you clearly state the issue is with the specific control and how it behaves, we can do the function for you.
We do also have some helpful selectable ISOs that should assist you with password resets and partitioning.
If you're reporting an issue with an image, and include all the details for us to identify and resolve the issue, feel free to make a ticket.
But just don't expect it to be resolved for immediate usage, it would take time and just be added to our list.
If everyone was provided completely dedicated resources on virtual servers, the biggest part of their appeal would be lost for most people. We do have "VDS" services, and we have dedicated servers if that's the route you should want or need to take, but they are priced accordingly.
As for bursting usage, it's completely fine and in most cases you can usually use it as if it's dedicated resources as long as your service itself is not essentially struggling to keep up with the resources it has allocated. Allow me to share all of today's warnings and powerdowns with you. Maybe this will paint a clearer picture.
For the I/O abuse above, the lowest usage out of all twenty-one of them, on an SSD256, was 431.15 transfers per second (number of I/O requests) with previous usages of 1,291.26 and 1,866.37 -- this is over a period of 8 hours. The average over a period of 24 hours was 444.53 TPS, 3105.85 read requests per second, 278.79 write requests per second, at an average data size of 3973.12 bytes read per second and 168.96 bytes write per second.
The highest usage was also on an SSD256. This one resulted in an immediate shutdown, as in an emergency shutdown with no prior warning. After the shutdown, the CPU usage on the node dropped from 66% to 51% (on a 32 core server) and I/O usage dropped from about 50% (of 8x1TB SSDs in HW RAID 10) to 10-15% so this is an example of our system taking action to improve the quality of service for everyone on that node as well. By emergency shutdown, it does not mean it gives the customer a few minutes and then shuts it down -- this only kicks in if it's also the result of overloading the server to an extreme level (and is super rare.) This one happened for a few hours, sustained, until the system intervened, which gives plenty of time for users to burst should they be installing a software or other temporarily intensive tasks. This was an average of 53,178.94 TPS with 425,032.16 read and 265.79 write requests per second. This was also around 4,000 bytes read per second and causing the device to reach near saturation levels.
Let me know if you have any suggestions for further improving the system based on the figures above, or if you have any more specific questions.
Even for limited support packages, response times will drastically improve after the next few days as we are almost caught up on the backlog of tickets.
We've sorted them out to where it's much faster to complete them now and should complete somewhere around 800 to 1,000 tickets in one day today. Most of these tickets are already resolved, via automation. We're just giving the final responses/closing it out and letting everyone know it was already resolved.
The threat of asking you to pay at VirMach, if you even slightly overuse one of your VPS (which you may not always monitor all the time, and let's say you might have gotten a DDOS on a non DDOS protected IP) made me end all my services in VirMach. You can pay $1.25 a month for a service, and a $25 surprise bill might even appear in a sudden. To me, even properly using VirMach VPSes worries me. At one time I had 10-20 VPSes on VirMach. In Vultr I had a bad code running that were using 100% of CPU for days (on one VPS) without even being warned by Vultr. After I found out about it on their panel I immediately fixed the issue, and my CPU usage on other VPSes were relatively low.
Sometimes I feel like processing power should also be pooled and averaged from all your VPSes just like bandwidth in Linode.
These were my experiences with VirMach, I'll stick with Vultr for core infrastructures in my project.
$25 may not sound like much especially by U.S. standards, but for example in Indonesia if you're using the minimum wage set by the government in the capital it's roughly 2 full days worth of work.
We haven't added $25 suspension/administration fees outside of automated chargebacks for probably a year. No one really paid those nor did we force people to pay them or send them to collections, it's just there to indicate the account was not in good standing but we shifted to mainly using another method to block future orders until previous issues are resolved first.
We don't see this as a positive. If we allow someone to max out CPU, which does usually occur as a result of errors, we prefer, and most customers prefer it's powered off. Most customers realize this, fix their code, and let us know it's resolved. It doesn't really end how you are imagining it.
The only difference is while on Vultr it took you days as you mentioned without even being warned until you happened to notice it, we would send a warning without power-down and then a warning with power-down should you miss the previous communication and the abnormal usage continues. These are what most cases are these days, the customer using the warning to correct the issue, outside of a few mass abusers that are clearly signing up for many accounts and maxing out usage on purpose, over and over, until they're suspended.
Generally, if you require a certain amount of processing power, we would recommend you go with packages that suit your needs instead if you plan on bursting them at the same time. The bandwidth idea though is interesting/feasible and perhaps if we can in the future we will do that as an option.
Thanks for the feedback.
Honestly i've choosed Virmach for:
But i would not put critical prod on Virmach cause of this:
I don't like much when a provider makes me feel like a bad customer or a kid ^^. But it's their business and their choices and i've accepted to deal with it.
I'm a little customer with non critical stuffs so i go with known providers on LET with good offers usually ; and i don't need support if it's not an issue on provider's side. So i was aware about what i dislike regarding Virmach but totally open to deal with it as i don't need much support, providers like Virmach do their best to offer great uptimes and fix technical issues quick.
Regarding your needs, it looks a bit like mine, so probably Virmach is a good fit.
I would like to suggest you to take a look also on NexusBytes (owned by @seriesn) and BuyVM (owned by @Francisco) ; these guys are always willing to help and makes you feel more than welcome. Their terms and AUP are btw super clear. Francisco is by far an awesome tech guy supported by an active community. UUnfortunately both of them doesnt offer discounts.