Xen and KVM - Who is using what and why?
-
@DustinB3403 said in Xen and KVM - Who is using what and why?:
@FATeknollogee said in Xen and KVM - Who is using what and why?:
You certainly did not install KVM like you would have had to with XS?
Does Scale let tinker/tweak "under the hood"?
btw, why/how is this different from FreeNAS "hiding" the BSD o/s?
FreeNAS is to Ubuntu as FreeBSD is to Debian.
No, Ubuntu adds the support and tons of important testing, versioning and features. FreeNAS does none of that.
-
@Dashrender said in Xen and KVM - Who is using what and why?:
@scottalanmiller said in Xen and KVM - Who is using what and why?:
@FATeknollogee said in Xen and KVM - Who is using what and why?:
You did not really "move" to KVM because Scale "hides" all the KVM?
You could say that about any system. But we "use" KVM instead of something else (like Xen or VMware). But you'd never say that we didn't move "from" Xen because it was hidden behind XenServer or that VMware ESXi is hidden behind vCenter. The hypervisor we are on is KVM and we definitely moved to it. That we use Scale as the interface to it, or virsh or whatever does matter in the big picture, but regardless of those tools, it's still KVM that we are running on.
Not sure I agree with that. It would depend on why you moved to Scale. If it was because of KVM, then I'll give you your point - the fact that it was part of the deal doesn't mean the same when you say " We moved from Xen to KVM" you didn't, you moved from Xen (or XenServer) to Scale, the fact that it was KVM, unless it was the driving factor, has little to do with it.
I don't agree at all. We were on Xen and ESXi, we moved, to what, KVM. You cannot say we didn't move from one to the other. Who packages or the reason that you move are not factors in "if you moved" and to "what".
-
@scottalanmiller said in Xen and KVM - Who is using what and why?:
@FATeknollogee said in Xen and KVM - Who is using what and why?:
You certainly did not install KVM like you would have had to with XS?
Does Scale let you tinker/tweak "under the hood"?
Does XS? In both cases... no, unless you are willing to give up support, then yes.
With XS, you can download the software & install on HW of your choice & still buy support if you'd like.
Can you do that with Scale?
-
@FATeknollogee said in Xen and KVM - Who is using what and why?:
@scottalanmiller said in Xen and KVM - Who is using what and why?:
@FATeknollogee said in Xen and KVM - Who is using what and why?:
You certainly did not install KVM like you would have had to with XS?
Does Scale let you tinker/tweak "under the hood"?
Does XS? In both cases... no, unless you are willing to give up support, then yes.
With XS, you can download the software & install on HW of your choice & still buy support if you'd like.
Can you do that with Scale?
So you are saying that the licensing of the management layer determines if you are using a hypervisor? I don't see how this question is related to the topic.
If you use Xen but manage it from a hosted SaaS, does it mean that you didn't move to Xen because you used a tool somewhere else that isn't Xen but since it manages Xen that's what you are going to focus on?
You are missing the simple point that we moved from Xen to KVM. No grey area, no sort ofs. It's as plain as can be. We also moved from XS as the management layer to Scale, but that's "also" and does not have anything effect on the answer "did we move to KVM."
Let's ask it in another way... if you think we didn't move to KVM, are you saying we are still on Xen and didn't move? What are you trying to say?
-
Let's try this with another example where you don't control the hardware....
If you move from Rackspace to Office 365 email, you have moved to Exchange. You don't control the hardware, you can't install Office 365 on anything you want, it is a service. But you are still getting your email through Exchange and Exchange is your MTA. You've moved to Exchange. That it is hosted isn't a factor in that.
-
@scottalanmiller said in Xen and KVM - Who is using what and why?:
Let's try this with another example where you don't control the hardware....
If you move from Rackspace to Office 365 email, you have moved to Exchange. You don't control the hardware, you can't install Office 365 on anything you want, it is a service. But you are still getting your email through Exchange and Exchange is your MTA. You've moved to Exchange. That it is hosted isn't a factor in that.
Right, but unless you moved specifically for the purpose of getting Exchange, which is where I was going in my post, then you shouldn't tell people you moved from Rackspace to Exchange - you should tell people you moved from Rackspace to O365 (sadly many people don't know O365 is Exchange).
The under lying technology isn't what's important unless that was the driving decision in going to that platform from a general discussion standpoint.
-
@Dashrender said in Xen and KVM - Who is using what and why?:
Right, but unless you moved specifically for the purpose of getting Exchange, which is where I was going in my post, then you shouldn't tell people you moved from Rackspace to Exchange
That's incorrect. The purpose is not relevant to the question. Did you move from Rackspace to Exchange? Yes. I don't see how any question to the simple truth is coming up. Was it Rackspace before? Yes. Is it Exchange now? Yes. Was it moved? Yes.
What is being missed here? In this question, how you do inject "purpose" into the equation? Why do you bring that up? It's not related to the question nor the answer.
-
@Dashrender said in Xen and KVM - Who is using what and why?:
The under lying technology isn't what's important unless that was the driving decision in going to that platform from a general discussion standpoint.
The question is solely about the underlying technology. Nothing else matters. You've injected a personal opinion into the equation to the point that you are saying that the action question doesn't matter and only the thing that you added matters to you but it was not asked about and doesn't matter here. If you want a discussion about why people move platforms, that's a great discussion to have. But it doesn't matter to the answer here.
-
@scottalanmiller said in Xen and KVM - Who is using what and why?:
@Dashrender said in Xen and KVM - Who is using what and why?:
The under lying technology isn't what's important unless that was the driving decision in going to that platform from a general discussion standpoint.
The question is solely about the underlying technology. Nothing else matters. You've injected a personal opinion into the equation to the point that you are saying that the action question doesn't matter and only the thing that you added matters to you but it was not asked about and doesn't matter here. If you want a discussion about why people move platforms, that's a great discussion to have. But it doesn't matter to the answer here.
The question - you mean the OP? ok sure, you're right it is
-
@Dashrender said in Xen and KVM - Who is using what and why?:
@scottalanmiller said in Xen and KVM - Who is using what and why?:
@Dashrender said in Xen and KVM - Who is using what and why?:
The under lying technology isn't what's important unless that was the driving decision in going to that platform from a general discussion standpoint.
The question is solely about the underlying technology. Nothing else matters. You've injected a personal opinion into the equation to the point that you are saying that the action question doesn't matter and only the thing that you added matters to you but it was not asked about and doesn't matter here. If you want a discussion about why people move platforms, that's a great discussion to have. But it doesn't matter to the answer here.
The question - you mean the OP? ok sure, you're right it is
Of course, the OP's question that I answered and was told repeatedly that I was wrong and that the answer to the question "what do you use now" is not KVM when we use KVM.
-
What's interesting here - and perhaps more to the point of what the OP wants - but didn't ask...
If Scale offered their interface on Xen or KVM, would it matter what was under the hood, if the higher layer offered all the same features?
-
WTF is your hang up @Dashrender? This is very clear.
To me it sounds like you took @FATeknollogee's post and conflated it with what @scottalanmiller actually said.
-
@Dashrender said in Xen and KVM - Who is using what and why?:
@scottalanmiller said in Xen and KVM - Who is using what and why?:
We've primarily moved to KVM before we are running Scale HC3 which has it built in under the hood.
So you like KVM these days better than XS?
Really a WTF moment to start off your entire involvement in the thread.
-
Saying one moved to Scale because it's KVM is like saying I moved to Nutanix because it's KVM!
Let me re-phrase the question: Was the move to Scale done because it was technically superior to XS or was it financially motivated?
-
@scottalanmiller said in Xen and KVM - Who is using what and why?:
@Dashrender said in Xen and KVM - Who is using what and why?:
@scottalanmiller said in Xen and KVM - Who is using what and why?:
@Dashrender said in Xen and KVM - Who is using what and why?:
@scottalanmiller said in Xen and KVM - Who is using what and why?:
We've primarily moved to KVM before we are running Scale HC3 which has it built in under the hood.
So you like KVM these days better than XS?
Odd conclusion to draw from that statement.
Not entirely. You moved to KVM before getting the Scale. If not because you like it better, then why?
No, we did not. We use KVM exclusively with Scale as an artefact of the Scale system. My wording must be odd above,
Well, the site is running on KVM also.
-
I use KVM. It's built into Red Hat, and really easy to use.
-
@FATeknollogee said in Xen and KVM - Who is using what and why?:
Saying one moved to Scale because it's KVM is like saying I moved to Nutanix because it's KVM!
Let me re-phrase the question: Was the move to Scale done because it was technically superior to XS or was it financially motivated?
It was financially motivated.
https://mangolassi.it/topic/6796/our-new-scale-cluster-arrives-tomorrow -
@Dashrender said in Xen and KVM - Who is using what and why?:
If Scale offered their interface on Xen or KVM, would it matter what was under the hood, if the higher layer offered all the same features?
What about the lower layers? If ALL the same features existed, then they'd be identical. But that would never really be the case. Xen and KVM have different performance characteristics, stability, change rates. All other things being equal, we'd have to evaluate which makes more sense. But that will never happen so is mostly moot.
What's interesting is that for years, it's the ecosystems that made the most difference anyway. KVM lacked tools like XenServer and XenOrchestra, backup vendor support and so forth. But until now, no one said "you didn't actually use Xen because the tooling was a factor in the decision." We are suddenly treating the Scale interface as a "special case" when the factors haven't changed. Why this sudden injection of "it's not really KVM" or whatever and not the same for other platforms previously?
And this question is asked regularly in the cloud space where people running OpenStack have one interface but have to choose between Xen, KVM, Hyper-V and VMware based on nothing but the hypervisor functions.
-
@scottalanmiller said in Xen and KVM - Who is using what and why?:
KVM lacked tools like XenServer and XenOrchestra, backup vendor support and so forth
It hasn't. Virt-Manager has been around for a long time. XenServer doesn't have any backup vendor support. The only support is agent based, which is exactly what KVM has. You also have backup options through QEMU and libvirt.
-
@FATeknollogee said in Xen and KVM - Who is using what and why?:
Let me re-phrase the question: Was the move to Scale done because it was technically superior to XS or was it financially motivated?
It's really apples and oranges. One is part of a solution, one is the full solution. If you used any other system, would you ask the same questions?
We are trying to break down something large, which is an architectural change drive by a change in support and use paradigm, and applying it to the underlying hypervisor component.
