Open Source Hypervisors: do we really have them? do we really need them?
-
@black3dynamite 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?:
@black3dynamite 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?:
@black3dynamite said in open source hypervisors: do we really have them? do we really need them?:
If it wasn't for XenSever, I could care less about using Xen.
Why is that? My experience is mostly the opposite, only found XS interesting recently and the maintenance of it made me essentially not care anymore. It's Xen that is really interesting. It's more advanced and has some VMware level features, like full fault tolerance that are removed in XS.
Because it was less of pain to get setup compare to my experience with Xen.
It's been a bit, but the big Xen distro was always Suse and getting it up and running is normally (or traditionally) nothing more than a checkbox on the install.
XS is popular because it installs as a distro, it's an "appliance" install.
It's been awhile but I remember trying Xen using Suse because of you. But my impatience got the best of me.
Hmmm.. any idea what issues you ran into? It's been a while since I did a new install.
-
@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?:
tht's my point in SMB, at least for the limited exposure I've seen about Xen in SMB. They go the XO + XS way, but to me this would mean just bind myself to XAPI, and I see this as a Citrix project no one else cares about. So what difference with Hyper-V?
Just because recently a number of SMBs have decided to layer on XAPI on Xen doesn't mean the things you are extrapolating.
- Using XS doesn't bind you to XAPI, it's just an interface you can trivially move away from.
Again: who really is able to do this in SMB?
- Lots of SMBs using Xen will use cloud which means no XAPI anyway
OK, this is a point. I've neglected a thing: I'm thinking about on premise installations. Use the cloud actually means they are relaying on non SMBs to manage Xen.
- XAPI is not tied to Citrix, we covered that
Well... but git commits' stats say the opposite
1733 David Scott 21.6% 1083 John Else 13.5% 1031 Rob Hoes 12.8% 563 Jon Ludlam 7.0% 335 Si Beaumont 4.2%all of those are citrix except David Scott, who was citrix when he developed the thing. But his last commit is from 2015, (when he leaved citrix?)
- XAPI and XS are protected by Linux and open source, so none of these concerns exist, this protection already kicked in and is specifically why these are now of interest when they were not before when under Citrix. LIterally this discussion exists now BECAUSE we've seen open source rescue these technologies from their closed source past
- It's all different from Hyper-V because Hyper-V IS bound, IS a single vendor and IS at risk to going away.
To me this can apply to Xen as it core, as you say, to KVM? (still crunching the repo). But when a SMB wants to deploy its on premise HV, the core itself is useful as much as the ecosystem around it. namely the basic one: HV management tools.
Xen as it core without XAPI is never seen in any SMB discussion I've looked at in recent years... so my question. Do really SMB pick Xen for its theoretical freedoms or just because its free of charge? Do they mind about the fact those tools can survive the main sponsor? How can I really "sell" them from a technical stand point?
My honest reaction in front of Xen as seen in SMB deployments is: ok you are now bound to citrix keeping xapi healty, as you could be bound to MS keeping Hyper-V healty.
I do not feel the same with distros: while a main sponsor is there, their contributing base is much wider.
When my pc will finish crunching KVM I will comment on it. Being a number of companies contributing to it (and to libvirt for those who do not go the vendor way - think about scale) seems enough value.
-
@scottalanmiller said in open source hypervisors: do we really have them? do we really need them?:
@black3dynamite 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?:
@black3dynamite 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?:
@black3dynamite said in open source hypervisors: do we really have them? do we really need them?:
If it wasn't for XenSever, I could care less about using Xen.
Why is that? My experience is mostly the opposite, only found XS interesting recently and the maintenance of it made me essentially not care anymore. It's Xen that is really interesting. It's more advanced and has some VMware level features, like full fault tolerance that are removed in XS.
Because it was less of pain to get setup compare to my experience with Xen.
It's been a bit, but the big Xen distro was always Suse and getting it up and running is normally (or traditionally) nothing more than a checkbox on the install.
XS is popular because it installs as a distro, it's an "appliance" install.
It's been awhile but I remember trying Xen using Suse because of you. But my impatience got the best of me.
Hmmm.. any idea what issues you ran into? It's been a while since I did a new install.
I was more of an Ubuntu/unity user and jumping in head first trying to use Suse just didn't feel right with me.
-
@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?:
tht's my point in SMB, at least for the limited exposure I've seen about Xen in SMB. They go the XO + XS way, but to me this would mean just bind myself to XAPI, and I see this as a Citrix project no one else cares about. So what difference with Hyper-V?
Just because recently a number of SMBs have decided to layer on XAPI on Xen doesn't mean the things you are extrapolating.
- Using XS doesn't bind you to XAPI, it's just an interface you can trivially move away from.
Again: who really is able to do this in SMB?
I'm confused. Like... anyone. I'm not sure where you perceive any lock in, so it is hard to explain why there is none.
-
@black3dynamite 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?:
@black3dynamite 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?:
@black3dynamite 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?:
@black3dynamite said in open source hypervisors: do we really have them? do we really need them?:
If it wasn't for XenSever, I could care less about using Xen.
Why is that? My experience is mostly the opposite, only found XS interesting recently and the maintenance of it made me essentially not care anymore. It's Xen that is really interesting. It's more advanced and has some VMware level features, like full fault tolerance that are removed in XS.
Because it was less of pain to get setup compare to my experience with Xen.
It's been a bit, but the big Xen distro was always Suse and getting it up and running is normally (or traditionally) nothing more than a checkbox on the install.
XS is popular because it installs as a distro, it's an "appliance" install.
It's been awhile but I remember trying Xen using Suse because of you. But my impatience got the best of me.
Hmmm.. any idea what issues you ran into? It's been a while since I did a new install.
I was more of an Ubuntu/unity user and jumping in head first trying to use Suse just didn't feel right with me.
Oh okay, that might do it.
-
@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?:
tht's my point in SMB, at least for the limited exposure I've seen about Xen in SMB. They go the XO + XS way, but to me this would mean just bind myself to XAPI, and I see this as a Citrix project no one else cares about. So what difference with Hyper-V?
Just because recently a number of SMBs have decided to layer on XAPI on Xen doesn't mean the things you are extrapolating.
- Using XS doesn't bind you to XAPI, it's just an interface you can trivially move away from.
Again: who really is able to do this in SMB?
- Lots of SMBs using Xen will use cloud which means no XAPI anyway
OK, this is a point. I've neglected a thing: I'm thinking about on premise installations. Use the cloud actually means they are relaying on non SMBs to manage Xen.
- XAPI is not tied to Citrix, we covered that
Well... but git commits' stats say the opposite
1733 David Scott 21.6% 1083 John Else 13.5% 1031 Rob Hoes 12.8% 563 Jon Ludlam 7.0% 335 Si Beaumont 4.2%all of those are citrix except David Scott, who was citrix when he developed the thing. But his last commit is from 2015, (when he leaved citrix?)
Except GIT commits only give a partial picture. That doesn't tell us what you think that it tells us.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
Xen as it core without XAPI is never seen in any SMB discussion I've looked at in recent years... so my question. Do really SMB pick Xen for its theoretical freedoms or just because its free of charge?
SMBs don't do things for good reason. We determined at one point that the average Hyper-V deployment in the SMB was literally by accident or confusion. SMBs are protected by Xen and KVM regardless of if the SMB knows it.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
My honest reaction in front of Xen as seen in SMB deployments is: ok you are now bound to citrix keeping xapi healty, as you could be bound to MS keeping Hyper-V healty.
But you simply are not. Nothing binds you to it. I don't know what creates this perception, but Xen is totally viable without XS or XAPI. Just because recently people are talking about XO a lot so XAPI gets brought up doesn't tell us that Xen is only viable with it or that you are bound to it or anything like that.
-
Think about OpenStack, loads of companies use Xen with OpenStack, no XAPI. Or think about the Suse and Ubuntu worlds. Xen is in no way limited to XAPI, no matter what the perception or popular conversation topics are.
-
my take on this:
-
ESXi free is limited, 8 vcpu per VM and that limit can be easily reached limit.
-
You can go with KVM and the community will provide you with better scripts to provide you with more advanced features, that are missing in ESXi free, especially regarding VM backups and automating them.
-
If you setup ESXi everyone will understand it or work with it, however if you setup KVM, the person after you will most likely curse you.
-
-
Also, when talking about XAPI, that's an API. So trivial compared to what we are talking about. Imagine if we talked about Vmware or Hyper-V in the same way... and only cared about the viability of these huge, heavily technical projects by one alternative (not even the main) API that has been recently added to them. An API is a tiny thing. XAPI is great and all, but it's just an API. Who contributes to it, how active it is.... who cares? It's just an API.
-
@msff-amman-Itofficer said in open source hypervisors: do we really have them? do we really need them?:
- If you setup ESXi everyone will understand it or work with it, however if you setup KVM, the person after you will most likely curse you.
But it's their own fault if something so easy is hard for them to handle
-
@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?:
My honest reaction in front of Xen as seen in SMB deployments is: ok you are now bound to citrix keeping xapi healty, as you could be bound to MS keeping Hyper-V healty.
But you simply are not. Nothing binds you to it. I don't know what creates this perception, but Xen is totally viable without XS or XAPI. Just because recently people are talking about XO a lot so XAPI gets brought up doesn't tell us that Xen is only viable with it or that you are bound to it or anything like that.
I feel this becouse I can't think about a deployment without backups and so. leave naubackup at a side. what alternatives you have if you kill XAPI? naubackup is great but planning a proper retention with it is difficutl for me, due to the way backups are kept (incremental/dedup etc...).
I'm probably wrong at this. Don't know.Let say you go Xen + Unitrends on Suse (is it feaseable?) now you have lock in in the backup more than with other solutions (9 over 10 you can choose at least between Altaro/Veeam/Nakivo/open solutions).
Now what makes this different from Hyper-V + YOUR_BACK_UP_SOLUTION?
Xen + XAPI +XO the only full open solution with proper functionality (can't think about HV without backup) but I do not feel it really open in the factsDon't know... I see Xen bound to one direction in SMB. Honestly I like it! But it doesn't seems to me that way really attains the real goal of an open source project...
KVM has similar concerns to me but lighter...
-
@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?:
Yes Canonical is way more "unstable" than IBM or Red Hat, but this is an example of how loosing the main sponsor usually means the projects start lagging and slowing down. Something which doesn't happen if the code is committed by etherogeneous subjects.
That's misleading. those projects are already slower, but that's not a benefit.
Think about two cars, one driving 140kph and one going 80kph. They both come into a town where the speed limit is 80kph. the faster car has to slow to the same speed as the slower car. That doesn't make the faster car slower or a negative, it only means that worst case, they are equal.
Having a big sponsor or set of sponsors means that the base speed isn't how fast the project can go, it can go really fast while it has the big sponsor and if it loses it, it just slows to the speed you'd normally have with normal committers.
And ANY risk of losing a sponsor like this is less than closed source losing a sponsor. Apply the same logic to Hyper-V or Vmware and suddenly they sound really, really scary. If MS find that Hyper-V is just losing it money, it can shut it down overnight without warning and make it illegal to download, install, copy, etc.
Fact is: if you slow down too much you start lag functionality. And you slowly fade in uselessness.
-
@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?:
Yes Canonical is way more "unstable" than IBM or Red Hat, but this is an example of how loosing the main sponsor usually means the projects start lagging and slowing down. Something which doesn't happen if the code is committed by etherogeneous subjects.
That's misleading. those projects are already slower, but that's not a benefit.
Think about two cars, one driving 140kph and one going 80kph. They both come into a town where the speed limit is 80kph. the faster car has to slow to the same speed as the slower car. That doesn't make the faster car slower or a negative, it only means that worst case, they are equal.
Having a big sponsor or set of sponsors means that the base speed isn't how fast the project can go, it can go really fast while it has the big sponsor and if it loses it, it just slows to the speed you'd normally have with normal committers.
And ANY risk of losing a sponsor like this is less than closed source losing a sponsor. Apply the same logic to Hyper-V or Vmware and suddenly they sound really, really scary. If MS find that Hyper-V is just losing it money, it can shut it down overnight without warning and make it illegal to download, install, copy, etc.
Fact is: if you slow down too much you start lag functionality. And you slowly fade in uselessness.
That's true, but the fear is that Xen or KVM lose their main sponsor and slow down, maybe only a little as another sponsor will likely step in (and XAPI is not something to fear slowing down, it is only an API.) But the fear with closed source is that there is no warning and the slow down is immediate and total (to zero.)
No matter how much you fear an open source slow down, it's better than the alternative.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
I feel this becouse I can't think about a deployment without backups and so. leave naubackup at a side. what alternatives you have if you kill XAPI? naubackup is great but planning a proper retention with it is difficutl for me, due to the way backups are kept (incremental/dedup etc...).
I'm probably wrong at this. Don't know.This is based around the assumption that backups have to be done at the hypervisor "agentless" level, which is a new thing and while it has merit and value, it is limited. Would it be great if Veeam had a native agentless backup for Xen? Absolutely. Does that mean that Xen does not have backups? Not at all. You don't back up Xen or KVM, you back up the workloads. And you are free to do that with agents the way that you always have.
And in the modern world, the way that backups need to work in many cases is dramatically different than they used to. The reality is is that there are old fashioned backups (agent) and this new type (agentless) and then REALLY modern (DevOps) and it's only this one middle ground that is popular in the SMB right now that Xen lacks.
There is no lack of backups. It's just that one style of backups isn't currently available for Xen outside of XO, and that being brand new. I don't see this as even a real concern, personally. Would it be nice to add it, you bet. But it's not a serious gap of any sort.
And Xen used to have agentless backups, but it was from a closed source vendor and like is always a risk with closed source software, they decided that it didn't make enough money and it was taken off of the market.
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
Let say you go Xen + Unitrends on Suse (is it feaseable?) now you have lock in in the backup more than with other solutions (9 over 10 you can choose at least between Altaro/Veeam/Nakivo/open solutions).
Number of solutions is rarely valuable. All that matters is that I have "more than enough" solutions. I can use Veeam to backup my workloads, or Unitrends, or StorageCraft or hundreds of others. Sure, more is "better" but only if in that "more" are options superior to the ones that I have. Which in the case of Hyper-V or VMware ESXi non-free do exist, but not because there are more options, simply because Veeam has better options there.
-
@scottalanmiller said in open source hypervisors: do we really have them? do we really need them?:
No matter how much you fear an open source slow down, it's better than the alternative.
That's a point. And it fits my experience as well! sold!
ok, KVM is more reassuring:
27 contributors come from Red Hat
198 from other sources...just looking now at how old non redhatters are...
-
@matteo-nunziati said in open source hypervisors: do we really have them? do we really need them?:
Xen + XAPI +XO the only full open solution with proper functionality (can't think about HV without backup) but I do not feel it really open in the facts
I feel the issue here is around these two assumptions. One that XAPI and XO are even important, I don't get where this is coming from. They are nice, but until there was XO, XS was pretty crappy and no one cared. But Xen was still great. And that you feel that things that are not what open means are required makes these things seem like something is wrong when there is nothing like that.
Xen + XAPI + XO is just one of several Xen approaches which is only one set of the Xen / KVM family of approaches. There is no lock in, no limits, no requirement to use those tools.
And they ARE open, completely and totally. There isn't anything not open in reality or in spirit about them. All of the "it's all one vendor" stuff is purely an odd perception.
So here are my core points that I think are why I don't agree with you...
- I dont' agree that there is any limit on the ecosystem
- I don't agree that XAPI is important at all
- I don't agree that backups need to be agentless
- I don't agree that XAPI commits are relevant to anything
- I don't agree that current vendor sponsorship and commits indicate a lack of community participation with the absence of that vendor
- I don't agree that open requires broad participation, it requires the access of a community, not its participation, those are totally different concepts. Open has never implied that in any way.
- I don't agree that any of the values of open source are missing here
All of those points I think are wrong individually, and I think that your feeling that Xen lacks value comes from all of them building upon one another.
-
@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?:
No matter how much you fear an open source slow down, it's better than the alternative.
That's a point. And it fits my experience as well! sold!
ok, KVM is more reassuring:
27 contributors come from Red Hat
198 from other sources...just looking now at how old non redhatters are...
How about Xen, instead of XAPI. XAPI is totally unimportant. Xen commits is where it will be interesting.
