Slashdot Mirror


Xen To Become Linux Foundation Collaborative Project

jrepin writes "The Linux Foundation, the nonprofit organization dedicated to accelerating the growth of Linux, today announced the Xen Project is becoming a Linux Foundation Collaborative Project. Linux Foundation Collaborative Projects are independently funded software projects that harness the power of collaborative development to fuel innovation across industries and ecosystems. The Xen Project is an open source virtualization platform licensed under the GPLv2 with a similar governance structure to the Linux kernel. Designed from the start for cloud computing, the project has more than a decade of development and is being used by more than 10 million users. As the project experiences contributions from an increasingly diverse group of companies, it is looking to The Linux Foundation to be a neutral forum for providing guidance and facilitating a collaborative network."

3 of 62 comments (clear)

  1. OpenVZ by tobia.conforto · · Score: 5, Insightful

    OpenVZ is very much like jails for Linux. I introduced it at my job four years ago and we've been using it ever since. I can attest to the savings in hardware overhead and in sysadmin time, compared to the alternatives of either full-blown VMs or all-services-in-one-Linux-box.

    Nowadays there is also LXC, which supposedly is the future for Linux jails, seeing as their patch-set got into the mainline kernel—something OpenVZ failed to achieve. But IMHO LXC is not as stable and reliable as OpenVZ, nor as well-isolated by default, which is an aspect that is too often neglected.

  2. Re:Xen's biggest obstacle right now by Anonymous Coward · · Score: 3, Insightful

    Agree 1000%. We have a fairly large VMWare cluster. Okay, maybe not that large, but it consists of 6*4U quad-socket, 8 core per socket servers with 512GB of RAM each. You can host a lot of stuff with that.

    What has happened is that any time a user says they need a new source code repo, a new application, another build server for their project, or whatever, is that we just spin up another virtual machine for them. That's how our IT middle management has sold this solution to our executives (being able to provide computing resources to the company on-demand with a rapid turnaround).

    What gets forgotten in all of this is that nobody does any proper engineering of the applications being ran to see if they need the resources being requested, or if they could be combined with other applications and run on the same instance. (For example, there is absolutely no need to have three separate CVS servers, two git servers, and two Perforce servers). Then we have users who for political reasons demand that they be given a software build environment for their project that is isolated from the build environment for another project. A quick analysis of resource usage statistics does not justify the creation of additional servers. Regardless, all of these requests are acquiesced to to make the other departments in the company happy.

    Then you have all of the old physical servers. Normally when a server gets long in the tooth, it's time to upgrade the application and put it on new hardware. Now with virtualization, we just take the same outdated application and simply P2V it, and it continues being the same unsupportable mess that it was before, now only it's running on stable hardware (a small positive to all of this I guess).

  3. Re:Xen's biggest obstacle right now by Anonymous Coward · · Score: 2, Insightful

    Can jails do live migration between hosts?
    How about live storage migration? (awesome when it comes time to migrate to a new SAN)
    Do they have a centralized management software that in the case of a hardware failure auto starts the jail on another machine?
    Templates?
    Snapshots?
    Dynamic resource management (i.e. CPU is busy on this machine, migrate the more idle VMs to another host to increase performance for the busy app)?
    Built in APIs for deploying new jails?
    Shared storage devices across physical hosts? (could be done with jails, but it would have to be setup on any host machine that you were going to run the jail on ahead of time)
    Separation of all system libraries so that updating the main host/any of the jails doesn't affect code running in your jails?

    Using virtualization also means that you can do things like apply a Windows datacenter license to a host, which means you can spin up as many Windows VMs for no extra cost on that host. I believe RedHat does the same for RHEL if you are running on RHEV. There may be plenty overhead, but if it was a big application that needs that much CPU power you should probably have it on bare metal anyways, which means that VMs are often your more idle machines.