Announcement

Collapse
No announcement yet.

OpenVZ & Parallels Cloud Server To Merge Into Open-Source Virtuozzo Core

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • OpenVZ & Parallels Cloud Server To Merge Into Open-Source Virtuozzo Core

    Phoronix: OpenVZ & Parallels Cloud Server To Merge Into Open-Source Virtuozzo Core

    Parallels Inc has realized they've been wrong for the past decade of not committing to the open-source development model in full for Parallels Cloud Server with OpenVZ being neglected as a result. However, in 2015 that shall change...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    This is great news. Virtuozzo has long been the undisputed leader in Linux containers, with features that completely outclass any other implementation e.g. solaris zones. The openvz folks are responsible for virtually all of the container technology that exists today in the mainline kernel. In my former job as a unix engineer at a fortune 100 company, we used vz containers to run full blown multi-role production servers, and I can tell you they are full featured, rock solid and bare metal fast. My only complaint was that the vz kernel versions lagged mainline by an appreciable amount. For instance, the latest vz server still ships with a kernel based on 2.6.32. However this latest move ought to bring everything into sync and reduce lead times appreciably.

    Comment


    • #3
      Competing with Docker

      Obviously, Docker changed the landscape.
      Openvz was already in the process to streamline more and more commits.
      But, if Virtuozzo wants to compete in container's domain, they must go the upper level, the orchestration.
      Openvz/virtuozzo has competences and experiences so they can do it.
      Openvz is robust and easy, and, depending on the orchestration tools provided in Virtuozzo Core, they can realy gain a lot from the container trend.
      In the container's world, VMWare is a joke so there are big opportunities in the enterprise's IT.
      Even Docker is disputed at the orchestration level (Kubernetes, Rocket, ...)
      Virtuozzo go ahead, and don't limit too much the "core" version.

      Comment


      • #4
        Originally posted by david_lynch View Post
        This is great news. Virtuozzo has long been the undisputed leader in Linux containers, with features that completely outclass any other implementation e.g. solaris zones. The openvz folks are responsible for virtually all of the container technology that exists today in the mainline kernel. In my former job as a unix engineer at a fortune 100 company, we used vz containers to run full blown multi-role production servers, and I can tell you they are full featured, rock solid and bare metal fast. My only complaint was that the vz kernel versions lagged mainline by an appreciable amount. For instance, the latest vz server still ships with a kernel based on 2.6.32. However this latest move ought to bring everything into sync and reduce lead times appreciably.
        Hm, you go around posting the same lament here, on LWN, ... where else?

        I start to sincerely doubt any "unix engineer" at a "fortune 100 company" would know so little about a technology being used at his workplace. But, hey, anything is possible.

        Anyway, OpenVZ folks being responsible for "virtually" all kernel container technology is a false statement. That's not even "paravirtually" true. But yes, they did contribute *a lot*.

        Also, OpenVZ kernel is NOT based on a vanilla 2.6.32 and is not "lagging" in any way. OpenVZ kernels closely follow RHEL kernels, the use them as their base.

        As I write this, current stable OpenVZ RHEL 6 kernel is based on RHEL's 2.6.32-504.1.3.el6. OpenVZ RHEL 5 kernel (soon to be EOL) is based on RHEL's 2.6.18-400.el5. There is also an OpenVZ RHEL 7 kernel in development, based on RHEL 7's variant of 3.10.0-xxx.n.m.el7.

        Anyone interested can check RHEL kernel's release dates and compare how quickly OpenVZ follows. There is also enough information about how a RHEL kernel relates to a vanilla kernel (backporting, etc.) freely available.

        I doubt this news means OpenVZ will contribute code to mainline kernel any faster than it is now. So no, the "gap" between the latest vanilla kernel and an OpenVZ kernel won't go away, because what you perceive as a "gap" is really just OpenVZ/Parallels using an enterprise level kernel from RHEL. Would you, as an "unix engineer" advise them not to?

        Comment


        • #5
          Originally posted by LightDot View Post
          Hm, you go around posting the same lament here, on LWN, ... where else?

          I start to sincerely doubt any "unix engineer" at a "fortune 100 company" would know so little about a technology being used at his workplace. But, hey, anything is possible.

          Anyway, OpenVZ folks being responsible for "virtually" all kernel container technology is a false statement. That's not even "paravirtually" true. But yes, they did contribute *a lot*.

          Also, OpenVZ kernel is NOT based on a vanilla 2.6.32 and is not "lagging" in any way. OpenVZ kernels closely follow RHEL kernels, the use them as their base.

          As I write this, current stable OpenVZ RHEL 6 kernel is based on RHEL's 2.6.32-504.1.3.el6. OpenVZ RHEL 5 kernel (soon to be EOL) is based on RHEL's 2.6.18-400.el5. There is also an OpenVZ RHEL 7 kernel in development, based on RHEL 7's variant of 3.10.0-xxx.n.m.el7.

          Anyone interested can check RHEL kernel's release dates and compare how quickly OpenVZ follows. There is also enough information about how a RHEL kernel relates to a vanilla kernel (backporting, etc.) freely available.

          I doubt this news means OpenVZ will contribute code to mainline kernel any faster than it is now. So no, the "gap" between the latest vanilla kernel and an OpenVZ kernel won't go away, because what you perceive as a "gap" is really just OpenVZ/Parallels using an enterprise level kernel from RHEL. Would you, as an "unix engineer" advise them not to?
          Oh Dear, I have a stalker - not sure whether to be annoyed, or just creeped out. At any rate, if you're going to try to play "gotcha", you ought to work on your reading comprehension, and make sure you have your facts right.

          Your spiel about the RHEL kernel vs vanilla is cute, but really beside the point, since nobody has said that the vz kernel is based directly on vanilla 2.6.32. Technically, they start with the Centos kernel, not RHEL, but I wouldn't expect the likes of you to know that

          There was also a SLES 2.6.16-based vz kernel, (which we actually started out with, but moved to the RHEL-based vz kernel as it was more heavily tested and more up to date) - but I wouldn't expect my obsessed stalker to know about the SLES-based vz kernel either.

          And this business of a "lament"? Here I was, expressing satisfaction with the new direction and you see only a "lament" - curious.

          if by "lament" you mean my observation about the gap in kernel version numbers between mainline and the current ovz kernel, it is a valid observation. In a lot of cases, 3rd party vendors look at a kernel version string to decide whether something is supported. Not only a problem of presenting a 2.6 version number, but the fact that it's not a vanilla RHEL or SLES kernel version is also a deal killer for these vendors. This sort of litmus test is often built into the install script. Sure, you could hack the install script and make it install anyway, but then when you call EMC to get support for a fiber channel attached storage issue - Surprise! you're not supported. So you can call that a lament, or you can call that whatever you want, but the this delta from the enterprise vendor kernels significantly hampered the success of vz containers for us. Not for lack of technical merit, nor lack of support from virtuozzo, who are BTW the sharpest tech people I've ever dealt with (I'm referring to the people in Russia, not the level one phone support folks) - but hampered by the reluctance of 3rd party vendors to extend support to a kernel that's not "mainline".

          So, my main point still stands. Reducing the delta between the vz kernel and mainline, and ultimately, being able to properly run vz containers on the mainline kernel will be a huge win.
          Last edited by david_lynch; 31 December 2014, 02:44 PM.

          Comment


          • #6
            Originally posted by david_lynch View Post
            Oh Dear, I have a stalker - not sure whether to be annoyed, or just creeped out.
            Look at the bright side, now you can go around telling people you are a "unix engineer" for a "fortune 100 company" with a "stalker", that should further improve your resume!

            In any case, I'm glad you've actually looked into OpenVZ in the mean time and also learned about vanilla and RHEL kernels. You should re-post your above lamentation on LWN, that will surely work wonders for your "fortune 100" career...

            Comment

            Working...
            X