Jump to content
SolusVM Community

SolusVM

Administrators
  • Content count

    2,847
  • Joined

  • Last visited

  • Days Won

    51

SolusVM last won the day on February 25 2017

SolusVM had the most liked content!

About SolusVM

  • Rank
    SolusVM Team

Profile Information

  • Gender

Recent Profile Visitors

7,427 profile views
  1. KVM rescue mode – introduced in SolusVM 1.20.05 – is a new way to empower your clients. With rescue mode your clients have the ability to perform self-service, repairing downed virtual machines. Rescue mode allows you and your clients to boot their downed virtual machines into a minimal install of Debian linux. Here they can either repair the VM, or backup their data for restoration. We’ll quickly go over how to use rescue mode. Upon logging into SolusVM, choose the virtual machine that needs booted into rescue mode. Upon choosing the VM, click on the new rescue mode icon available in the dashboard. In the rescue mode admin, you’ll be able to choose the rescue mode image that you would prefer to use. In most cases the 64 bit kernel will work best. Confirm that you would like to put the VM into rescue mode. Please note, if the virtual machine is NOT down, it will be rebooted. In most instances if your virtual machine is online, it will not require rescue mode enabled. After confirmation, your VM will be booted into rescue mode, and you’ll receive the temporary SSH details that can be used to repair your virtual machine. Once you have repaired your virtual machine, you can now disable rescue mode. Upon disabling rescue mode, the VM will be rebooted into your primary operating system. Service providers, would you like to share this document with your clients? You can download the screenshots here. The post Using the new KVM Rescue Mode, with SolusVM 1.20.05 appeared first on SolusVM. View the full article
  2. Wouldn’t it be nice if you could show your clients leniency when unexpected bandwidth surges occur? Why should you be forced to penalize your clients when they experience success — reward them, and build customer loyalty. Now you can, with SolusVM 1.20.04, introducing the ability to rate limit virtual machines upon reaching their bandwidth limit. This is a powerful new feature that allows you to completely change the way you sell virtual machines, and compete with the 3 stooges. Scenario 1: rate limit then suspend upon hard limit. The new rate limiting feature allows you to set a soft bandwidth limit and a hard bandwidth limit. Upon reaching the soft limit, users will be rate-limited to your pre-defined network speeds. When they reach the hard limit, the virtual machine will be suspended and shut down. Offer your clients an advantage only SolusVM hosts can offer, with a rate limited bandwidth allowance. Example configuration below: limit_speed_instead_of_suspend = true limit_speed_over_amount = 1024 limit_speed = 5 Scenario 2: unlimited rate limited bandwidth. One way to offer extremely affordable virtual machines, would be to offer a limited amount of uncapped bandwidth. Upon reaching that cap, virtual machines could be rate limited, for an unlimited amount of bandwidth. Imagine something along the lines of 5GB uncapped bandwidth, then unlimited bandwidth capped at 5 mbit per second. Perfect for a small development server. Example configuration below: limit_speed_instead_of_suspend = true limit_speed_over_amount = 5000 limit_speed = 5 Scenario 3: permanently rate limited virtual machines. Finally, there’s another way to sell virtual machines, which uses an existing feature. Using the port speed limitation, you can sell virtual machines that are permanently rate limited. You can do this to reduce risk, such as limiting the damage caused by DDoS attacks or limit your variable bandwidth expenses, and pass on the savings to your customers. How do you sell? These are just a few examples of the ways you can differentiate your business and grow! Reach out on social – Twitter | Facebook – tell us how we can help you expand how you sell VMs! The post New Ways to Sell Virtual Machines. appeared first on SolusVM. View the full article
  3. SolusVM – 1.20.04 Released

    SolusVM Version 1 – 20.04 has now been released! Release notes The post SolusVM – 1.20.04 Released appeared first on SolusVM. View the full article
  4. UPDATE – 6th January 1.03PM GMT 0 New Xen kernels are being tested by upstream which should hopefully fix booting issues of PV guests. UPDATE – 6th January 12.15PM GMT 0 An updated kernel is available for OpenVZ on CentOS 6. What better way to start 2018 than with news of two serious vulnerabilities in all kinds of computing devices! In this post we’ll summarize the problems and explain what SolusVM customers need to do. The vulnerabilities, which have been named Meltdown and Spectre, are hardware bugs that were reported by security researchers on January 3rd 2018. They affect a large number of Intel, AMD and ARM computing architectures. What are Meltdown and Spectre? In brief, “Meltdown” affects the most fundamental isolation of user applications from the operating system, which could allow a program to access memory being used by another program, or the Operating System; while “Spectre” is reported to break the isolation between error-free applications. You can read more at https://meltdownattack.com/. How does this affect your SolusVM software? These issues are not specific to SolusVM, or any specific software application: they are created by hardware bugs that affect a large number of different computing platforms, from smartphones and desktop PCs to datacenter infrastructure. From what we know today, it seems that the problems cannot be fixed at the hardware level: they have to be addressed by software patches at the OS level. There are two potential impacts on your SolusVM software: At the installer/package level. For new installs, we pull the relevant OS components direct from the repo: these should already be patched, apart from OpenVZ. For existing SolusVM installs, you’ll need to update your OS components via yum in the usual way, specifically the kernel. The following updates are available from upstream for your hypervisors: KVM: CentOS 7 – Updates available CentOS 6 – Updates available Xen: CentOS 7 – Updates available CentOS 6 – Updates available If a Xen PV guest is updated to the new CentOS 6 kernel (2.6.32-696.18.7.el6.x86_64) it may prevent the guest from booting. OpenVZ: Virtuozzo Linux 7 – No updates available as of yet CentOS 6 – Updates available Keep an eye on this blog post, and the @SolusVM twitter feed, for the latest news. The post Information about Meltdown & Spectre vulnerabilities. appeared first on SolusVM. View the full article
  5. SolusVM Version 1 – 20.01 has now been released! Release notes View the full article
  6. Nginx & Letsencrypt

    Actually try this: rm -rf /usr/local/svmstack/letsencrypt/store That will delete the old registration data. Then run: /usr/local/svmstack/letsencrypt/letsencrypt -i
  7. Nginx & Letsencrypt

    Try this: yum clean all yum update svmstack-letsencrypt That should fix it.
  8. Nginx & Letsencrypt

    Hi, Do you have port 80 open on the master? it needs it to connect to the letsencrypt servers.
  9. SolusVM Version 1 – 20.00 has now been released! Release notes View the full article
  10. Kernel RHEL5 028stab120.2

    Fixed a kernel panic triggerable via the move_pages() syscall. [ Change log/downloads... ] --Vvs 12:00, 14 September 2016 (EDT) View the full article
  11. Kernel RHEL5 028stab120.2

    Fixed a kernel panic triggerable via the move_pages() syscall. [ Change log/downloads... ] --Vvs 12:00, 14 September 2016 (EDT) View the full article
  12. Kernel RHEL5 028stab120.2

    Fixed a kernel panic triggerable via the move_pages() syscall. [ Change log/downloads... ] --Vvs 12:00, 14 September 2016 (EDT) View the full article
  13. Kernel RHEL5 028stab120.2

    Fixed a kernel panic triggerable via the move_pages() syscall. [ Change log/downloads... ] --Vvs 12:00, 14 September 2016 (EDT) View the full article
  14. Kernel RHEL6 042stab117.14

    Rebase to RHEL6u8 kernel 2.6.32-642.el6 (security, bug fixes, enhancements, see RHSA-2016-0855). Fixes and enhancements in KVM, UBC, ext4, networking, cpt. [ Change log/downloads... ] --VvS 15:00, 13 September 2016 (EDT) View the full article
  15. Kernel RHEL6 042stab117.14

    Rebase to RHEL6u8 kernel 2.6.32-642.el6 kvm: reporting emulation failures to userspace. (CVE-2010-5313, CVE-2014-7842) File descriptors passed over unix sockets are not properly accounted. (CVE-2013-4312) x86: espfix not working for 32-bit KVM paravirt guests. (CVE-2014-8134) Buffer overflow with fraglist larger than MAX_SKB_FRAGS + 2 in virtio-net. (CVE-2015-5156) Mounting ext2 fs e2fsprogs/tests/f_orphan as ext4 crashes system. (CVE-2015-7509) MTU value is not validated in IPv6 stack causing packet loss. (CVE-2015-8215) Null pointer dereference when mounting ext4. (CVE-2015-8324) IPv6 connect causes DoS via NULL pointer dereference. (CVE-2015-8543) An attacker with knowledge of a connections client IP, server IP, and server port can abuse the challenge ACK mechanism and remotely inject or control a TCP stream contents in a connection between a Linux device and its connected client/server. (CVE-2016-5696) Numabalanced acquire cgroup_mutex for a long time. (PSBM-26897) CPU hotplug improvements (PSBM-46773). cpt: incorrect restore of SKB resulting in warnings in tcp_recvmsg(). (PSBM-39332, PSBM-46741) cpt: crash in nfs_fscache_dup_uniq_id on dump of container with NFS mounts inside. (PSBM-47216) cpt: crash in svc_age_temp_xprts_now() on stop of container with NFS mount. (PSBM-47515) cpt: crash on closing restored Unix sockets. (PSBM-47529) cpt: fixed restore of shared mounts. (PSBM-47639, OVZ-6779) cpt: crash after restore of Unix sockets with in-flight file descriptors. (PSBM-51254, PSBM-51351) ext4: crash in ext4_kill_sb() on mount of non-EXT4 filesystems (042stab114.2+ are affected) (PSBM-47782). swap: forbid exceeding ub swappages limit on global memory pressure. (PSBM-47836). 25-second delays can happen while logging in to systemd-based containers after container migration or host vzreboot. (PSBM-47889) CISCO UCS eNIC driver wraps untagged traffic into vlan0. (PSBM-51149) aacraid: Crash in aac_intr_normal(). (042stab112.15+ are affected) PSBM-49814) Fixed operation of iputils-ping-20150815 (debian-9) inside containers. (OVZ-6744) module: removed warning about waiting module removal. (OVZ-6748) fs.mqueue.* sysctls can be changed inside containers. (OVZ-6757) [ Change log/downloads... ] --VvS 15:00, 13 September 2016 (EDT) View the full article
×