Open Source Hypervisors: do we really have them? do we really need them?
-
@DustinB3403 said in open source hypervisors: do we really have them? do we really need them?:
Xen is the parent to XenServer. Generally when people speak of Xen they refer to XenServer.
Actually no, normally they do not. That's mostly unique to the SMB space and mostly to SW and it carried over here a bit.
-
@FATeknollogee said in open source hypervisors: do we really have them? do we really need them?:
Just want to make sure I'm following this correctly. Is this the "Xen" that you guys are referring to ? https://www.xenproject.org/
If yes, what "GUI's" are available to manage Xen?
XenCenter, Xen Orchestra, OpenStack, AWS, RS, and many more. No shortage of options
-
@JaredBusch said in open source hypervisors: do we really have them? do we really need them?:
Then entire discussion is whacked. But this statement...
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
Disclosure: I really like open source and looking at code for simplier projects really saved my day, just trying to remove some doubts of mine about KVM and Xen.
Reading code? how much of your employers time are your wasting with personal interest? If I caught an IT employee doing this they would be disciplined, and eventually terminated for continuing to do so.
Are you a trained software developer? Are you paid to inspect code? What the ever living hell do you think gives you the right to screw your employer over like that?
A lot of employers encourage this, actually. But they limit the time used for it. Like 5% or something. Places like Google and Facebook encourage it for personal development (in the person growth sense) and to encourage loyalty.
-
@JaredBusch When you develop code using open souce libraries reading the code is usually a way to shorten devel time. Almost all libraries (both open or closed) I've worked with have holes in the docs. Reading the code in open souce saves thevday. Really.
But my point was: when a project grows really big and the major baker is corporate, is really possible that someone else will be able to fork and continue? And who? If it is a company which overrides the previous one is this not like MS selling hyper-v to another company?
-
@scottalanmiller said in open source hypervisors: do we really have them? do we really need them?:
@FATeknollogee said in open source hypervisors: do we really have them? do we really need them?:
Just want to make sure I'm following this correctly. Is this the "Xen" that you guys are referring to ? https://www.xenproject.org/
If yes, what "GUI's" are available to manage Xen?
XenCenter, Xen Orchestra, OpenStack, AWS, RS, and many more. No shortage of options
I didn't know you could use XenCenter to manage a Xen install? Why wouldn't this be a "popular" option?
Of the methods you listed above, which one is your favorite & why?
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
But my point was: when a project grows really big and the major baker is corporate, is really possible that someone else will be able to fork and continue? And who?
Well it could be anyone. Look at TrueCrypt. It went away by surprise. People stepped up to take it over INSTANTLY.
Look at Unity, took about one day after being dropped by Canonical before a company was formed to take it over, and that's a garbage project that no one cares about.
KVM isn't like either of these, it's already not owned by RH but by Linux itself. Who takes care of Linux? RH, out of concern for people saying things like you are now, already went to great lengths to ensure that it's covered by other entities so that if RH goes under, literally nothing happens. Same with Xen but long, long ago. Xen isn't handled by Citrix at all, so the "concern" is already solved in that case.
Your concern is totally unfounded from a conceptual standpoint. I don't know how to make this clearer. There is NO risk to these projects like this, this is a "meteor" risk. Yes, a meteor could wipe out earth, but it is so unlikely that planning your risk panic around it is crazy. It's just not going to happen, and if it did the impact would be so great that your planning and worry would be pointless anyway.
And in the case of KVM, it's already split up with other huge entities, like IBM, who have a huge stake and can't let it go away. Same with Xen, IBM is deeply in bed with both. As is HPE, Scale, Canonical, Suse, Intel, etc.
Not only is your fear totally unfounded, your one current sponsor theory is unfounded. It's a false fear based on a false sense of ownership.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
If it is a company which overrides the previous one is this not like MS selling hyper-v to another company?
All, it's nothing like that. One because MS likely would not do that but just cancel it. No one would buy Hyper-V, it would make no sense financially. Has MS done that before? No, they just cancel projects and make them go away. And no developers outside of MS know the code, so there is no one able to pick it up. And it isn't open so the existing developers can't continue to support it.
This is open source, open in every sense, as open and open gets. The projects are already visible and known to thousands of companies that work on the code, the developers are already in place, the licensing is already in place, the ability to collaborate is there, the existing RH or Citrix developers would not be expected to stop working on the project just because sponsorship for the work is lost, there is no need for a buyer, no need for a seller, etc.
Literally every aspect is different. There is no comparison.
-
@FATeknollogee said in open source hypervisors: do we really have them? do we really need them?:
I didn't know you could use XenCenter to manage a Xen install? Why wouldn't this be a "popular" option?
Because it requires XAPI which we don't like and XC is complete garbage and even when using XS we consider it to not exist. XO is SO much better, "everyone" in the XS community considered XO to be the interface to XS, not XC. That XC exists is just not important as it has been replaced by the ecosystem by a universally better, free and open alternative that does not require Windows.
-
@FATeknollogee said in open source hypervisors: do we really have them? do we really need them?:
Of the methods you listed above, which one is your favorite & why?
Depends on the use case, if I'm using XS, I'd use XO every time because it is XO that makes you use XS in the first place.
If I'm building a cloud, I'd use OpenStack. Etc.
-
@matteo-nunziati you also have an assumption that developers from a vendor work on a product because they are at that vendor. While that can be true, it often is not and is not an assumption that you can make. Your assertion is that because developers work at Red Hat or have worked there, that it is Red Hat having them work on the project. Often it is because they work on the project that Red Hat hires them. Your basis for believing that a vendor is tied to a project because they employ or have employed people who work on their pet projects isn't based in reality. That certainly does happen, but the opposite happens quite commonly, too. This is open source, but you are still thinking of the risks as if it was closed source. Or you keep saying it is not open to your standards, but you are defining open in a way that has no connection to open source software. Once you realize these are really open, none of your concerns exist.
But ALL of your concerns DO apply to all closed sourced software. So if you read your concerns carefully, they all explain why Xen and KVM matter so much. You're actually making a great argument for why open source is critical, but because you keep thinking that Xen and KVM are not open, you aren't seeing how you are proving their value and how they protect you against the concerns you are having.
-
@scottalanmiller said in open source hypervisors: do we really have them? do we really need them?:
@msff-amman-Itofficer said in open source hypervisors: do we really have them? do we really need them?:
If you want to bypass all this just get ESXi licensed, and your set.
Doing all that is easier than getting the license, I've tried.
If you want the power of KVM without the complexity, Scale HC3 is the way to go.
I don't think KVM has any complexity. I always thought XenServer was too complex to manage. Cross referencing UUIDs to image names is annoying. Not being able to store images in whatever directory you want is annoying. Not being able to store ISOs on your host is annoying (not using XO).
KVM is stupid simple. Click the hypervisor role on CentOS install. Done. You can store images in 1000 different directories if you want. Virsh and the virt tools (virt-sysprep, virt-customize, virt-builder, etc) give you so much power. Networking is done with dns-masq so it's easy to set reservations and do DNS within the host.
Single host deployments are stupid easy. More than one host deployments add some complexity but using orchestration it makes everything easy.
-
@stacksofplates said in open source hypervisors: do we really have them? do we really need them?:
More than one host deployments add some complexity but using orchestration it makes everything easy.
Details, please?
-
@FATeknollogee said in open source hypervisors: do we really have them? do we really need them?:
@stacksofplates said in open source hypervisors: do we really have them? do we really need them?:
More than one host deployments add some complexity but using orchestration it makes everything easy.
Details, please?
You just manage the host like anything else. I ship the template to each host. I clone the template with the correct MAC and it gets whatever reservation it's supposed to. Then Ansible does all of the work. 99% of my systems don't get backed up because it's all code based. The 1% that do have backing stores and agent based backups that are orchestrated and are part of the code base for that VM.
-
You essentially treat your hosts like data center regions on a cloud provider. VMs replicate within themselves. The hosts are just a place for them to run. There is nothing special about any of the hosts.
-
@stacksofplates said in open source hypervisors: do we really have them? do we really need them?:
VMs replicate within themselves.
On a single host or across multiple hosts?
-
@FATeknollogee said in open source hypervisors: do we really have them? do we really need them?:
@stacksofplates said in open source hypervisors: do we really have them? do we really need them?:
VMs replicate within themselves.
On a single host or across multiple hosts?
Across multiple. This has to be set up obviously. I usually use floating IPs and if there is stateful data that needs replicated I'll use Gluster. But if it's just stateless data I'll just use floating IPs.
-
@stacksofplates said in open source hypervisors: do we really have them? do we really need them?:
Across multiple.
Thx, kinda what I thought.
...if there is stateful data that needs replicated I'll use Gluster.
I think I'm going to revisit oVirt
-
@scottalanmiller said in open source hypervisors: do we really have them? do we really need them?:
@FATeknollogee said in open source hypervisors: do we really have them? do we really need them?:
Just want to make sure I'm following this correctly. Is this the "Xen" that you guys are referring to ? https://www.xenproject.org/
If yes, what "GUI's" are available to manage Xen?
XenCenter, Xen Orchestra, OpenStack, AWS, RS, and many more. No shortage of options
OpenStack is really a CMP, than just a hypervisor GUI.
-
@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?:
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.
Who outside of google project zero is really doing this though? No F1000 I worked for ever did their own open source audit.
-
@John-Nicholson 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?:
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.
Who outside of google project zero is really doing this though? No F1000 I worked for ever did their own open source audit.
All of them that I've worked for do. Including smaller non-F1000. It's actually quite common.
