Open Source Hypervisors: do we really have them? do we really need them?
-
It is a couple of nights I was thinking about this and probably I've just twisted my mind but...
what open source type-1 hypervisors do we really have? and do we really need them (ok this is provocative)?Of course we have both KVM and Xen but let think about them a little more... do not just think about the form but also the facts.
As first, what are benefits of open source against freeware in SMB? I mean that while you can charge for open source, one of the most relevant criteria to pick open source in SMB is that product's quality is high but its cost is low/null
Usually SMB do not pay support contracts with Red Hat or Suse: they go the community way. So it is common to overlook at differences in these 2 fields (free vs open).
Discriminating between open source software or just freeware should lead us to some strategic advantages, namely:
- The freedom to run the program as you wish, for any purpose (freedom 0).
- The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help your neighbor (freedom 2).
- The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
Now with KVM and Xen against Hyper-V:
-
point 1 is there, and this is a real advantage vs hyper-v: you can not use hyper-v as you want, you have the EULA
-
point 2 IMHO is unlikely in real life:
KVM/libvirt is basically a Red Hat show. If Red Hat will drop KVM there will really be someone which will step up and will continue the development? In the end Red Hat just buyed Qumranet who invented KVM, if ex-Qumranet employees will be motivated to move to something else, there is someone else skilled enough and involved enough to keep the project go on? Maybe Suse? IMHO we have corporate open source which lives up to the company interest nothing else. Do this mind SMB IT managers here?
With Xen the issue is different: most of the new functionality comes from XAPI. while Xen is community, XAPI is a fully Citrix stuff. I do not think that, if Citrix will drop XAPI, anyone will jump in. Look at the current situation: XAPI is so non standard wrt Xen Project source code, that no one is packaging it and current Citrix efforts are focused only on Centos because they use it for Dom 0. Libvirt lags a lot here.
-
point 3: really anyone cares to download hyper-V server from MS website rather than get KVM/Xen from friend's usb pen?
-
point 4: this is connected to point 2: how many non corporate (Red Hat/Qumranet and Citrix) related commits have been merged in the main code of KVM/libvirt or XAPI?
I mean that while 2 of the main type-1 hypervisors are open source in the form, I think that none of them is currently really open in the facts as no developement community is there. Just a user community. But this is also true for Hyper-V.
What do you think about my musing?!
How much do you care about points 2 and 4 for your company? -
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
Of course we have both KVM and Xen but let think about them a little more...
And BHyve
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
- The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
- point 2 IMHO is unlikely in real life:
This freedom goes far, far beyond what an SMB "will do". The ability to study code is not important for you to use yourself, but for the improvements, support, auditing and protection it brings because you "can", not because you "will". For example, thousands of companies actually do look at and audit this code, bringing, in many cases, MORE benefits to the SMB than to the enterprise, because the SMB does not pay for inspection teams, yet reaps the benefits from them.
The idea that open source requires you to look at the code to have value is false. The code visibility is protection in many ways simply because you own the source, not because you personally read it.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
KVM/libvirt is basically a Red Hat show. If Red Hat will drop KVM there will really be someone which will step up and will continue the development?
It's not owned by or controlled by RH. RH is not likely to drop it, less likely that MS dropping Hyper-V. Knowing that someone else will pick it up and that all they will do is lose control is one of the many benefits of open source to us, the consumers. It keeps RH from dropping things in a way that we don't have protection with for closed source.
KVM is part of Linux, not RH. It's heavily contributed to by Canonical and Suse but, more importantly, IBM. Even if RH walked away today, KVM is not in the slightest danger. If MS did that to Hyper-V, it would be over - period.
So yes, the open source nature here provides us the most extreme level of benefits and protection that exist in the industry.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
IMHO we have corporate open source which lives up to the company interest nothing else. Do this mind SMB IT managers here?
My opinion is as far from this as possible. Open source is specifically protection against this. Nothing carries this risk more than closed source. Open source is, in fact, the sole protection against this problem. What you describe is literally the key risk of closed source software, not open source.
Open source is only at this kind of risk when it has no customers which, in turn, means there is no one affected which, in turn again, means no risk. The nature of open source is that if it is used, someone will have an interest to support it. Unlike closed source where the owner of the IP has to have a will and a means to provide support.
How many closed source projects have gone away because the owner decided it was not profitable yet there were customers wanting to use it? Tons, nearly all. This is the expected end of all closed source software. Even Windows itself did this, leaving Windows NT in its wake. But actual Windows, the DOS family OS from 1991, has been gone for nearly two decades. No one has the right to release it. This is why OS/2 disappeared. This is why you can't buy Maniac Mansion.
Open source protects you as long as someone needs the software.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
With Xen the issue is different: most of the new functionality comes from XAPI.
I don't feel that that is true. Certainly some functionality, but the biggest users of Xen and the most advanced deployments don't even use the XAPI.
-
@scottalanmiller said in open source hypervisors: do we really have them? do we really need them?:
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
Of course we have both KVM and Xen but let think about them a little more...
And BHyve
type-2?
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
XAPI is a fully Citrix stuff. I do not think that, if Citrix will drop XAPI, anyone will jump in.
Actually XAPI is made by the Linux Foundation (with sponsorship from Citrix), not by Citrix themselves. It is owned by Xen, as a part of Linux, not be Citrix. XAPI is the base for XCP which Citrix then uses to make XenServer. XAPI is already out of Citrix' hands and developed separately.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
XAPI is so non standard wrt Xen Project source code, that no one is packaging it and current Citrix efforts are focused only on Centos because they use it for Dom 0.
On their wiki they say that the package for Ubuntu. Maybe this has changed, but given the nature of XCP and XAPI, would you want it anywhere but CentOS? Is this in any way a negative?
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
- point 3: really anyone cares to download hyper-V server from MS website rather than get KVM/Xen from friend's usb pen?
This may sound silly, but it is a point of protection. Any sensible business should be very concerned about this. Like before, this is about protection to ensure that you are safe, not something you use every day.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
- point 4: this is connected to point 2: how many non corporate (Red Hat/Qumranet and Citrix) related commits have been merged in the main code of KVM/libvirt or XAPI?
Again, protection comes from what can be done, not what is done. It's like asking how many times has your bullet proof vest saved you? We hope, none. But if you ever get shot, you'll be glad that decades of not getting shot didn't convince you to go into battle without proper protection.
-
@scottalanmiller said in open source hypervisors: do we really have them? do we really need them?:
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
XAPI is a fully Citrix stuff. I do not think that, if Citrix will drop XAPI, anyone will jump in.
Actually XAPI is made by the Linux Foundation (with sponsorship from Citrix), not by Citrix themselves. It is owned by Xen, as a part of Linux, not be Citrix. XAPI is the base for XCP which Citrix then uses to make XenServer. XAPI is already out of Citrix' hands and developed separately.
I agree with that. At the lest Citrix event I attend, they couldn't care less about XenServer and reccommend VMware.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
I mean that while 2 of the main type-1 hypervisors are open source in the form, I think that none of them is currently really open in the facts as no developement community is there. Just a user community. But this is also true for Hyper-V.
I'm not sure what you mean. Just become commits come from only companies does not in any way take away from them being open. There are development communities. Companies like IBM and Red Hat have both internal communities that are extremely important, as well as inter-corporation communities. If someone becomes a heavy commiter to KVM, it is likely that one of these big companies will hire them to ensure the continued development. But it sounds like you see that commitment and protection and inherently diminishing the value?
Open source is not about thousands of individuals in basements equally turning out a few lines of code to come together to a project. It's about openness, freedom, end user protection, idea sharing, safety, gift economy, human development and so forth. I don't see anything negative or concerning here at all. This is exactly how the majority of healthy, open, free software projects would be expected to be when everything is exactly as it should be.
-
@Francesco-Provino said in open source hypervisors: do we really have them? do we really need them?:
@scottalanmiller said in open source hypervisors: do we really have them? do we really need them?:
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
XAPI is a fully Citrix stuff. I do not think that, if Citrix will drop XAPI, anyone will jump in.
Actually XAPI is made by the Linux Foundation (with sponsorship from Citrix), not by Citrix themselves. It is owned by Xen, as a part of Linux, not be Citrix. XAPI is the base for XCP which Citrix then uses to make XenServer. XAPI is already out of Citrix' hands and developed separately.
I agree with that. At the lest Citrix event I attend, they couldn't care less about XenServer and reccommend VMware.
Yes, Citrix gave up on that long ago.
-
I worked with Citrix to get stuff certified on KVM, they were thrilled to have the work done.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
@scottalanmiller said in open source hypervisors: do we really have them? do we really need them?:
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
Of course we have both KVM and Xen but let think about them a little more...
And BHyve
type-2?
No, type 1.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
1 The freedom to run the program as you wish, for any purpose (freedom 0).
2 The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
3 The freedom to redistribute copies so you can help your neighbor (freedom 2).
4 The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.So from this...
Point 1: I think this is huge and alone provides enough value to make any further discussion academic. No matter how little other points matter, this one is so big that it defines the importance to all businesses of every size and type.
Point 2: The freedom and protection that this brings are important regardless of if we do it internally or not. that we can or that others can provides huge value and protection to even the smallest business.
Point 3: This is really just an aspect of point 1, but it matters because it's what keeps us from losing access to what already exists.
Point 4: This is big because it encourages more contributions from more companies in the future and keeps since entities from being able to take code in a direction that does not make sense for the greater good. This protection helps us every day, but we don't see it, because it "just works." -
@matteo-nunziati Xen can be fully used without XAPI, that are also an OSS project.
XenServer is the Xen package with XAPI, but any enterprise distro provide Xen WITHOUTH XAPI, namely SuSe and Ubuntu. You can use it effectively with libvirt or the xl toolstack.At the moment I don't see any risk associated with Xen being dropped by anyone, because it's the widely used hypervisor in the world. Almost any public cloud use that. Just the fact that AWS is built on Xen it's a guarantee that it cannot became abandonware in any way. Amazon alone could support the entire Xen development with 0.1% the revenues from the AWS cloud. They have all the interest in maintain Xen healthy.
-
An example of Point 4 working for us is LibreOffice. Remember when it was just OpenOffice and stagnating? Point 4 is what granted all of us the protection that the project would continue and thrive, which it did. Anyone using LibreOffice is a recipient of point 4 from a product that 15 years ago no one would have guessed would ever need that kind of protection.
-
@Francesco-Provino said in open source hypervisors: do we really have them? do we really need them?:
@matteo-nunziati Xen can be fully used without XAPI, that are also an OSS project.
XenServer is the Xen package with XAPI, but any enterprise distro provide Xen WITHOUTH XAPI, namely SuSe and Ubuntu. You can use it effectively with libvirt or the xl toolstack.At the moment I don't see any risk associated with Xen being dropped by anyone, because it's the widely used hypervisor in the world. Almost any public cloud use that. Just the fact that AWS is built on Xen it's a guarantee that it cannot became abandonware in any way. Amazon alone could support the entire Xen development with 0.1% the revenues from the AWS cloud. They have all the interest in maintain Xen healthy.
And IBM's SoftLayer and Rackspace (which was important until this morning) are both Xen as well. Neither is on par with Amazon, but both are large enough to support it without any other vendors involved.
And OpenStack is heavily involved with Xen (sans XAPI). Not as much as with KVM today, but is a major player in the private cloud space with Xen.
