Howdy, Stranger!

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


Waveride (by EDIS) - 4Gb RAM/50G HDD/4 vCPU/2TB Traffic OpenVZ+Solus 5EUR/mo - Page 3
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.

Waveride (by EDIS) - 4Gb RAM/50G HDD/4 vCPU/2TB Traffic OpenVZ+Solus 5EUR/mo

13»

Comments

  • any upgrade (for disks) available?

  • disk-upgrades: only by upgrading to larger standard plans. no bespoke plans on waveride.

  • rm_rm_ IPv6 Advocate, Veteran
    edited April 2013

    @ExPl0ReR said: technically speaking there is no difference for the client, because a 4/0 and a 2/4 VPS will have 4 GB of memory available.

    There is very much a difference to the client. If the RAM is "2 GB guaranteed, 4GB burst", any usage beyond 2GB marks them as a potential target to be OOM-killed.
    On LEB/LET this has to be honestly advertised as "RAM: 2GB, Burst: 4 GB".
    I really hope you're not trying to pull a dishonest overselling trick and just "new to OpenVZ", seeing how EDIS had no OpenVZ offers before.

    The RAM listed in offers is the maximum amount that is available for a VPS to use at one time (provided that everyone else on the node isn't maxing out their RAM usage at the same time in which case you would have less than the maximum amount available...and a lot of disk swapping on the node and performance would grind to a crawl).

    When the node runs out of memory, it's the tasks of clients using their Burst RAM that are getting killed first. If you stay within your guaranteed RAM you can be safe and just have a brief slowdown. But those using beyond Guaranteed and into Burst RAM, will have the processes they run terminated.

  • @apollo15 said: Burstable RAM

    fixd

    @apollo15 said: Burstable RAM in SolusVM is vSwap on .32 ovz kernels.

    no, only if explicitely enabled.

  • Hello guys

    @rm_ said: On LEB/LET this has to be honestly advertised as "RAM: 2GB, Burst: 4 GB".

    I really hope you're not trying to pull a dishonest overselling trick and just "new to OpenVZ", seeing how EDIS had no OpenVZ offers before.

    I would like to assure you, that EDIS tried hard to build its reputation in this forum and has no intent to cheat on anyone. IMHO this would be the wrong place to play jokes ... with all the professionals around here ;-)

    Honestly, EDIS is new to OpenVZ. We have some years of experience with linux virtual server containers and with libvirt/qemu on KVM systems, but OpenVZ seems to be slighty different. I personally only looked at the final available RAM in my VPS and this showed the full RAM amounts ... was quite amazed that we suddenly had this "burst thingy" ;-)

    There is no need to change the product specifications.
    We intended to sell 4+ GB plans and we continue to do so.

    As @William already posted: It has been "fixed." ;-)

    We amended the server templates in SolusVM to the indicated RAM values and disabled burst.

    ** All new servers will be provisioned with the indicated values **
    ** All existing servers have been modified and will show correct values after a manual restart of the VPS **

    I would like to say HUGE THANK YOU to all the guys who contributed to this solution ;-)
    We appreciate it! (and learned a lot today ;-)

    Cheers,
    Gerhard @EDIS @Waveride

  • Purchased a VPS - iptables_nat is not working...

  • kelwin said "Purchased a VPS - iptables_nat is not working.."

    iptables_nat is working on mine but ipt_recent and xt_connlimit aren't (Debian 6 64-bit)

    Testing iptables...

    Testing ip_tables/iptable_filter...OK

    Testing ipt_LOG...OK
    Testing ipt_multiport/xt_multiport...OK
    Testing ipt_REJECT...OK
    Testing ipt_state/xt_state...OK
    Testing ipt_limit/xt_limit...OK
    Testing ipt_recent...FAILED [Error: iptables: No chain/target/match by that name.] - Required for PORTFLOOD and PORTKNOCKING features
    Testing xt_connlimit...FAILED [Error: iptables: No chain/target/match by that name.] - Required for CONNLIMIT feature
    Testing ipt_owner/xt_owner...OK
    Testing iptable_nat/ipt_REDIRECT...OK
    Testing iptable_nat/ipt_DNAT...OK

    RESULT: csf will function on this server but some features will not work due to some missing iptables modules [2]

  • Centos x86_64:

    iptables: Flushing firewall rules: [ OK ]

    iptables: Setting chains to policy ACCEPT: mangle filter [ OK ]
    iptables: Unloading modules: [ OK ]
    iptables: Applying firewall rules: FATAL: Module ip_tables not found.
    iptables-restore v1.4.7: iptables-restore: unable to initialize table 'nat'

    Error occurred at line: 58

    Try `iptables-restore -h' or 'iptables-restore --help' for more information.
    [FAILED]

  • @ExPl0ReR said: We intended to sell 4+ GB plans and we continue to do so.

    Well that's what's important, I'm sure people can be slightly patient for this sort of deal. I entirely agree with your "no support" approach since it's obviously cutting the cost, but will you be providing some sort of forum or the like where customers can discuss issues? We've already had some as per above but we probably need something better than this thread in the long term.

  • @nutjob: fully agree with you. I am perfectly happy with the no-support approach and I am willing and able to resolve any issues within my VPS on my own.

    However, after a bit of investigation it appears that my above problem is a result of OpenVZ setup / configuration. If I combine this with what @ExPl0ReR said earlier ("EDIS is new to OpenVZ", "OpenVZ seems to be slighty different"), I thought I'd post here, since they only want emergency tickets submitted via their ticketing system.

    Coming back to what @nutjob says: yes, for such problems a process should be defined. Obviously, there are issues which we cannot resolve in our VMs.

  • ExPl0ReRExPl0ReR Member
    edited April 2013

    @nutjob @kelwin

    You are absolutely right! Our "no support"-policy refers to questions like "my error 500 document in apache is not working", "can you setup LAMP for me?" or questions like "phpbb mysql can't connect to db server" stuff. We're happy to help and support clients if there is something from our side that needs to be adjusted or fixed.

    There will be 2 things coming up in the very near future:

    • a simple waveride website with general background information, TOS and what "no support" exactly means.
    • an EDIS forum to address everything around EDIS and Waveride products.

    Sometimes it is cool to quickly support somebody directly here in LET or in other forums on the web. This is the place where issues probably shall be addressed if a provider is not willing to change things. The primary contact should be the providers support-department though.

    Please don't take me wrong, I appreciate that things are openly being discussed here. Particularly on this very new system of ours, this makes it easy to get all the feedback in one place and have initial problems fixed quickly.

    Have nice Sunday wherever you are!
    Gerhard @EDIS @Waveride

  • If it will lower prices further you should also try some non-unique IP4 plans (NAT only) with an IP6, ala lowendspirit.com, but with higher specs.

  • @ExPl0ReR: looking forward to seeing that forum come to life :)

    Any chance you can look into my iptables_nat problem in the meantime? :)

    I found the following, suggesting it might be a virtualization configuration issue:

    http://tinyurl.com/cv83eud

    http://tinyurl.com/cs72m53

    Many thanks in advance!

  • KrisKris Member
    edited April 2013

    @ExPl0ReR said: We're happy to help and support clients if there is something from our side that needs to be adjusted or fixed.

    On host-node, you need to modprobe for these (can not be done within machines) - Also needs to be added to run at startup, if / when machine reboots.

    Sounds like they're setup within the .conf's, just the machine isn't set for them. That or needs to be added via something like :

    vzctl set 420 --iptables ipt_REJECT --iptables ipt_tos --iptables ipt_TOS --iptables ipt_LOG --iptables ip_conntrack --iptables ipt_limit --iptables ipt_multiport --iptables iptable_filter --iptables iptable_mangle --iptables ipt_TCPMSS --iptables ipt_tcpmss --iptables ipt_ttl --iptables ipt_length --iptables ipt_state --iptables iptable_nat --iptables ip_nat_ftp --save
    

    HN to be run:

    modprobe ipt_MASQUERADE
    modprobe ipt_helper
    modprobe ipt_REDIRECT
    modprobe ppp_generic
    modprobe ppp_async
    modprobe ppp_deflate
    modprobe ppp_mppe
    modprobe ipt_state
    modprobe iptable_filter
    modprobe ip_conntrack
    modprobe ipt_TCPMSS
    modprobe ipt_LOG
    modprobe ipt_TOS
    modprobe tun
    modprobe iptable_nat
    modprobe ipt_length
    modprobe ipt_tcpmss
    modprobe iptable_mangle
    modprobe ipt_limit
    modprobe ipt_tos
    modprobe iptable_filter
    modprobe ipt_helper
    modprobe ipt_tos
    modprobe ipt_ttl
    modprobe ipt_REJECT
    modprobe ipt_recent
    modprobe ip_nat_ftp
    modprobe xt_connlimit
    
  • @nutjob @kelwin @Kris @DomainBop

    Hi guys!
    please restart you VPS and try again - thanks a lot!
    (and sorry for the silence ... we had to investigate)

    please share your results with us, TNX

    Gerhard

  • @ExPl0ReR all IP tables modules are working now. Thx

  • @DomainBop TNX a lot for your feedback! We're glad that this is sorted now ;-)

  • Awesome! Works for me as well.

    Thank you very much :)

  • @kelwin YAIYY! ;-)

  • rm_rm_ IPv6 Advocate, Veteran
    edited April 2013

    An issue related to this that many providers face, is that all these modules disappear (are not loaded, again), after the node reboots. I hope you ensured this is properly dealt with, so users don't have to find out much later that this is indeed the case.

  • @rm_ said: I hope you ensured this is properly dealt with ...

    YES SIR :-)

  • GaryGary Member

    How many nodes are there? The one I'm on, the time is set incorrectly. I've opened a ticket. :)

  • @Gary said: The one I'm on, the time is set incorrectly. I've opened a ticket. :)

    We currently operate a handful of nodes - we just started 5 days ago, but growing fast ;-)
    Hi! the time was wrong by 2 minutes. The remaining 2 hours are caused by the time-zone

    Gerhard

  • GaryGary Member

    Nah, it wasn't just the time zone Gerhard.

    Before:

    # dpkg-reconfigure tzdata && curl --silent nblug.org:13 | egrep "2013"
    
    Current default time zone: 'Europe/London'
    Local time is now:      Fri Apr 26 02:51:33 BST 2013.
    Universal Time is now:  Fri Apr 26 01:51:33 UTC 2013.
    
    Thu, 25 Apr 2013 23:49:54 +0000
    

    now:

    # dpkg-reconfigure tzdata && curl --silent nblug.org:13 | egrep "2013"
    
    Current default time zone: 'Europe/London'
    Local time is now:      Fri Apr 26 13:32:29 BST 2013. 
    Universal Time is now:  Fri Apr 26 12:32:29 UTC 2013.
    
    Fri, 26 Apr 2013 12:32:29 +0000
    

    My container had the same timezone both times. Before, it thought BST was 2 hours later than it actually was. Now it's correct. Anyway, fixed now so thanks :)

  • ExPl0ReRExPl0ReR Member
    edited April 2013

    @Gary said: Nah, it wasn't just the time zone Gerhard.

    Gary, I was told it was (only) the timezone but I heard some colleagues talking about something else as well. I was told that they fixed it. Sorry for that.
    I assume you are absolutely right with what you posted. I can only assure you, that the servers are now NTP sync.
    Have a great weekend!
    Gerhard

  • GaryGary Member

    Not a problem Gerhard, you have a good one too :)

Sign In or Register to comment.