At the hosting provider I own we originally started offering Virtual Private Servers late 2008 to address the needs of our clients who were outgrowing shared but didn’t yet want to move to a full-blown dedicated environment. We did offer VPSs for about 6 months before the HyperVM scare at FsckVPS happened where dozens of VPS nodes were wiped clean and data lost. We then decided to discontinue HyperVM and worked on migrating our existing VPS clients to other providers we worked with and trusted to be reliable.
The Good
Fast forward to late 2009 when we brought our first new SolusVM VPS server node online. SolusVM has been an exceptional control panel with a good list of features and while it is missing some basic features such as bandwidth reports, cpu graphs, and memory graphs SolusVM has been working on improving their software over time. We can handle a few missing “features” as long as we know that those features are in development and will be added.
The administration control panel and the user side of the control panel are very clean and concise while still being very powerful. The only gripes we originally had with SolusVM was the inability to customize the client side templates and re-brand the solution however they did enable this ability and so far we love the control panel in this aspect.
SolusVM does offer a forum where you can post your questions and issues and receive support from others using the software as well and fairly regularly a SolusVM staff member will also stop by and help out as well. There is also a support ticket system should you have an issue that is urgent or that does require some privacy. Our general experiences with SolusVM support over both methods has been fairly good – I wouldn’t go so far as to say great but the support definitely has not been bad.
The Bad
As with any solution the support staff can only support their solution and they cannot support third party issues such as hardware issues with a server, networking issues outside of the VPS system itself, etc… We understand this however we are facing an issue currently that is indeed a part of the SolusVM control panel ecosystem and yet we’re receiving no support on the matter.
The particular issue we are facing is that no matter what speed we set for individual VPSs in the control panel they are limited to a total limit of around 10 megabit/second transfer speed. Before contacting SolusVM support we did do some testing to make sure that the server itself was configured correctly and able to transfer at rates up to 100 megabit/second:
[root@boreas ~]# wget http://speedtest.dal01.softlayer.com/downloads/test100.zip
–2010-04-22 17:02:27– http://speedtest.dal01.softlayer.com/downloads/test100.zip
Resolving speedtest.dal01.softlayer.com… 74.86.116.210
Connecting to speedtest.dal01.softlayer.com|74.86.116.210|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 104874307 (100M) [application/zip]
Saving to: `test100.zip’
100%[========================>] 104,874,307 9.55M/s in 9.7s
Even with providing this information to SolusVM they responded that they were able to reproduce the issue on our servers but that the problem was not a SolusVM problem and that they could only provide support to the panel itself. They stated that they could not and would not support issues with our server or network.
We’re quite a bit on the fence with SolusVM due to this lack of basic support. It’s obvious that the server itself is fully capable of 100megabit speeds and that the networking is fully capable of these speeds as well and yet SolusVM support is telling us that it’s a server or networking issue and that they won’t help. To be clear the only thing that has been done to this server is that we installed it with a basic CentOS5 installation and then performed the SolusVM installation.
I’ll be sure to update this post once SolusVM does get back to us either letting us know that they are going to help with the issue or that we’re on our own to find another better supported control panel.
Update
It seems that they’re unwilling to help in any way/shape/form which is really unfortunate. Up until now we’ve had nothing but good things to say about SolusVM and their support but it looks like there isn’t much support available.
Jason from SolusVM support got back to me saying they tested the rate limiting on our servers and that it is working and suggested that we test the feature ourselves. They also stated that they tested teh speed limiting on their test servers and that it was working fine. They went even further and said that it was an OpenVZ issue and not an issue with their control panel. The tech went far enough to say that they are not willing to spend hours of their time investigating the issue when all we really wanted was a bit of effort on their part.
Update Number 2
I let the support tech that I was dealing with, Jason, know about my suspicion of what was causing the issue and I let them know about this post. My suspicion is that since we are using SoftLayer servers where ETH0 is Private Networking and ETH1 is public instead of ETH0 being public as it is on most servers at most providers that perhaps this was causing issues.
Jason got back to me stating that they will not be blackmailed by a bad review and that he is passing the ticket over to Phill as he is no longer going to respond to the ticket. Phill did get back to me very quickly (within about 10 minutes) and hopefully we’ll be able to identify the issue.
Update Number 3
Phill did get back to me letting me know that the traffic shaping is indeed hard-coded to ETH0 and suggested that we either change our public networking to ETH0 or that they perhaps that SolusVM should do public network detection.
From speaking with Phill it seems as though he thought that our issue was that the Traffic Shaping wasn’t properly applying to the VMs and come to find out it’s not but that isn’t our primary issue. Ultimately there is still the issue that SolusVM hard-codes eth0 into it’s traffic shaping and we’ve uncovered this today.
As for the issues where the VPSs port speeds are dropping for no apparent reason, we’re still working on this for sure. Hopefully SolusVM support will be willing to assist with this.
Update Number 4
So it seems that SolusVM wanted me to remove any excerpts used from emails/tickets with their support. I’ve done so as requested.
Update Number 5
Ultimately after finally getting Phill at SolusVM to actually discuss the issue with me he suggested that I drop all traffic shaping rules on the host node. We did so and amazingly all of the issues disappeared. This was after hours upon hours of SolusVM saying it wasn’t an issue with their control panel – it turns out that it was actually an issue with the control panel having hard coded eth0 into their traffic shaping settings in their control panel. Every SoftLayer server uses eth0 as private networking and eth1 as public networking which means that SolusVM’s way of performing traffic shaping simply didn’t work correctly in our environment.
While this does mean that we’re unable to perform any traffic shaping per VPS via SolusVM until they enable the feature to select your primary eth device and that we have to do so manually if we wish to do so – we’d rather have to do some manual work and have it work correctly than to rely on the control panel and have it flawed. We’ve voiced our opinion in the ticket that SolusVM should give the option to choose an alternate public ethernet device and we’re doing so here as well.
As far as I’m concerned the issue is ultimately resolved but SolusVM does have a long way to go before it gets back to where we would feel comfortable recommending it to our partners and other providers we socially network with.
7 comments
Mike, I just saw your update #4. I hate it when companies see negative reviews and hide behind their TOS/AUP/etc to get them changed or pulled down.
In fact, a year ago I started caching all negative reviews I read if I could get to them before companies had them edited.
@Scott Swezey
Interesting – ultimately I hope to not see this as a negative review. I’m going to continue updating this post as I work with support and hopefully it will end on a positive note.
@MikeDVB
That would be cool if it did work out like that. I’ll keep an eye on your post and update my cache(s) as needed to truthfully represent what you are reporting here.
In the meantime you may wish to swap the interface names via udev. This will require that you edit /etc/udev/rules.d/[67]0_persistent-net.rules and swap the two interface names, then change each of ifcfg-eth[01] and route-eth0 (to route-eth1) the configuration files in /etc/sysconfig/network-scripts and reboot. Make sure to be logged into the VPN and the KVM for the server in the case that anything was missed. We can also do this for you via a ticket, if required, but be very specific in that you need only the interfaces renamed via udev as these requests are worded incorrectly at times.
** I have never used solusvm and do not know if there are any virtual switch or interface changes that you would have to make after renaming the interfaces.
@Anthony L.
If this was a new server without customers already on it I’d consider doing that… If SolusVM documented that they needed the public interface to be eth0 — I would have looked into doing this before putting clients on the server.
There are numerous issues we’ve run into with SolusVM where things were hard-coded or simply were not documented. Another example is that you cannot have *any* IP addresses assigned in the server before installing SolusVM – you have to do so in SolusVM once it’s installed.
Ultimately we’ve just disabled the traffic shaping (we don’t limit traffic on VPSs anyhow) and the intermittent bandwidth issues have been resolved so ultimately I’m not terribly worried about the shaping itself. The primary issue was that the misconfiguration was causing the VPS connections to have issues where they could only get 5~10 MBPS at times.
Fast forward to late 2009 when we brought our first new SolusVM VPS server node online. SolusVM has been an exceptional control panel with a good list of features and while it is missing some basic features such as bandwidth reports, cpu graphs, and memory graphs SolusVM has been working on improving their software over time. We can handle a few missing “features” as long as we know that those features are in development and will be added.
Mike, I just saw your update #4. I hate it when companies see negative reviews and hide behind their TOS/AUP/etc to get them changed or pulled down.
In fact, a year ago I started caching all negative reviews I read if I could get to them before companies had them edited.
Case in point, I got to yours before they asked you to edit it: http://www.scottswezey.com/uploads/solusvm-review.html
@Scott Swezey
Interesting – ultimately I hope to not see this as a negative review. I’m going to continue updating this post as I work with support and hopefully it will end on a positive note.
@MikeDVB
That would be cool if it did work out like that. I’ll keep an eye on your post and update my cache(s) as needed to truthfully represent what you are reporting here.
In the meantime you may wish to swap the interface names via udev. This will require that you edit /etc/udev/rules.d/[67]0_persistent-net.rules and swap the two interface names, then change each of ifcfg-eth[01] and route-eth0 (to route-eth1) the configuration files in /etc/sysconfig/network-scripts and reboot. Make sure to be logged into the VPN and the KVM for the server in the case that anything was missed. We can also do this for you via a ticket, if required, but be very specific in that you need only the interfaces renamed via udev as these requests are worded incorrectly at times.
** I have never used solusvm and do not know if there are any virtual switch or interface changes that you would have to make after renaming the interfaces.
@Anthony L.
If this was a new server without customers already on it I’d consider doing that… If SolusVM documented that they needed the public interface to be eth0 — I would have looked into doing this before putting clients on the server.
There are numerous issues we’ve run into with SolusVM where things were hard-coded or simply were not documented. Another example is that you cannot have *any* IP addresses assigned in the server before installing SolusVM – you have to do so in SolusVM once it’s installed.
Ultimately we’ve just disabled the traffic shaping (we don’t limit traffic on VPSs anyhow) and the intermittent bandwidth issues have been resolved so ultimately I’m not terribly worried about the shaping itself. The primary issue was that the misconfiguration was causing the VPS connections to have issues where they could only get 5~10 MBPS at times.