KVM or VMWare
-
@pete-s said in KVM or VMWare:
It isn't the ability to automate that is the problem. It's the availablility of easy to use tools that is the problem.
Thats the whole point I'm making.
KVM is hard to automate. Not that it's impossible, but the tooling doesn't exist to where you can easily automate like with VMware.
-
@stacksofplates said in KVM or VMWare:
@pete-s said in KVM or VMWare:
It isn't the ability to automate that is the problem. It's the availablility of easy to use tools that is the problem.
Thats the whole point I'm making.
KVM is hard to automate. Not that it's impossible, but the tooling doesn't exist to where you can easily automate like with VMware.
And that's a very good point. That's why here at Vates, we made various efforts in XCP-ng/Xen Orchestra, providing multiple solutions: Packer, Terraform and even Ansible integration. That's also why Xen Orchestra really makes sense as a "middleware", as a single central point to consume with its API. Like vCenter in fact.
This is a true way to create value on top of it. The other aspect is all about integration, like we did with Netbox for example (sync all VMs and hosts, with their IP address, config and such to Netbox).
Automation is key.
Some links/resources:
-
@travisdh1 said in KVM or VMWare:
@eddiejennings said in KVM or VMWare:
@travisdh1 said in KVM or VMWare:
@stacksofplates said in KVM or VMWare:
@travisdh1 said in KVM or VMWare:
@irj said in KVM or VMWare:
@francesco-provino said in KVM or VMWare:
@WLS-ITGuy I haven’t been in this forum for years, and after years I still see similar questions and the same arguing…
Do yourself a favor and learn something useful like Terraform to automate VMware or similar stuff, the real deal today is not wasting your time reinventing the wheel and doing manual operations, not saving a few bucks on hypervisor’s license.
I agree here. Many on here don't understand the benefits of IaC and proper SDLC because they haven't been exposed to it yet. Penny wise and pound foolish.
Granted many of these one man shops don't have the resources (IT employees) to do it. If you're fixing printers you don't have the bandwidth to do this kind of stuff. Either way there is still pain in the long run for not doing automation, but for them it's just not feasible.
I'm all in favor of automation.
What I question is why you NEED VMWare to automate things? I've done it with XenServer/XCP-NG, and I don't see why anyone couldn't also automate KVM based things as well.
Can you give examples of this automation? I have a feeling the terms aren't exactly the same here.
What I'm thinking of in this case is using Ansible to provision and build and manage VMs and/or the host server.
I’ve been working with this in my home lab, and the virt module seems pretty limited in what it can do. For making a new VM, I’m basically creating and executing a script that runs virt-install to make the VM, which is similar to what the Fedora Project does for VM creation.
This is an example I've used before for XenServer/XCP-NG. https://jrisch.medium.com/using-ansible-to-automate-vm-creation-on-xenserver-d092aa484a06
So two things with this. The first is, what was even the point of using Ansible here? They're just running shell commands for everything. You lose huge advantages of Ansible here. It's really no different than a Bash script at this point.
The second is, this isn't the type of automation I'm talking about. You can do this type of rudimentary stuff with KVM also, but it's all based on cli tools.
Someone mentioned VDI the other day on the site. Say you want to automate bringing up a system for a user automatically when they need a VDI. With these tools you'd either need to use CGI scripts which is essentially a no go, or you'd have to have some way to expose Ansible with AWX, Jenkins, Tower, etc. But you can't just expose Ansible because that doesn't give the end user an easy way to get something. So now you have to either have build a pipeline in Jenkins with remote triggers, or set up Tower/AWX with provisioning callbacks, or something similar. Then you give the user some interface that can then send a request to your middle layer or software to define the request. It's a ton of unnecessary work.
vSphere would either be a RESTful call from a form, or some IaC tool like Pulumi which is embedded in your app that would let them define what they need and it would call vSphere and build it.
The amount of work to automate KVM vs VMware is just too much unless you have a niche case like a cloud provider.
-
@olivier said in KVM or VMWare:
@stacksofplates said in KVM or VMWare:
@pete-s said in KVM or VMWare:
It isn't the ability to automate that is the problem. It's the availablility of easy to use tools that is the problem.
Thats the whole point I'm making.
KVM is hard to automate. Not that it's impossible, but the tooling doesn't exist to where you can easily automate like with VMware.
And that's a very good point. That's why here at Vates, we made various efforts in XCP-ng/Xen Orchestra, providing multiple solutions: Packer, Terraform and even Ansible integration. That's also why Xen Orchestra really makes sense as a "middleware", as a single central point to consume with its API. Like vCenter in fact.
This is a true way to create value on top of it. The other aspect is all about integration, like we did with Netbox for example (sync all VMs and hosts, with their IP address, config and such to Netbox).
Right VMware or Xen Orchestra. If the tool isn't built with an API first mindset, the work needed to automate it greatly increases.
-
@stacksofplates said in KVM or VMWare:
@olivier said in KVM or VMWare:
@stacksofplates said in KVM or VMWare:
@pete-s said in KVM or VMWare:
It isn't the ability to automate that is the problem. It's the availablility of easy to use tools that is the problem.
Thats the whole point I'm making.
KVM is hard to automate. Not that it's impossible, but the tooling doesn't exist to where you can easily automate like with VMware.
And that's a very good point. That's why here at Vates, we made various efforts in XCP-ng/Xen Orchestra, providing multiple solutions: Packer, Terraform and even Ansible integration. That's also why Xen Orchestra really makes sense as a "middleware", as a single central point to consume with its API. Like vCenter in fact.
This is a true way to create value on top of it. The other aspect is all about integration, like we did with Netbox for example (sync all VMs and hosts, with their IP address, config and such to Netbox).
Right VMware or Xen Orchestra. If the tool isn't built with an API first mindset, the work needed to automate it greatly increases.
I agree. And to be honest, we learnt it "by accident" (ie our API was made for our internal usage). But now we are working more on the direction of "API as first class citizen", thanks to the large feedback we got from our users. I'm happy we took the right "overall design" decisions at first, allowing us to rely on Xen Orchestra as a central point (vs one UI per host, which can be handy but doesn't scale)
-
@olivier I know you have to sell it, but it's foolish to propose Xen in 2021.
Xen has been a phasing-out hypervisor (and platform, considering the ecosystem) in the last 5-6 years.Develop solutions based on Xen does not makes any sense, even big player with huge investments on Xen have abandon it or are actively retiring it.
-
haha nice try @Francesco-Provino This is foolish to think that
First, this is not true. Then, the number of active Xen users is growing (a reasonable part is due to XCP-ng). And even the number of contributors (also thanks to us).
Xen, by design, is more secure than the other "big" Open Source alternative. The only downside is that's requiring more knowledge to move it forward.
The main issues was 1. Citrix acquiring it but not pushing it fast enough, because not being part of their core skills and 2. not having any Open Source knowledge.
As a true type 1, you can accomplish great things, and yes it requires some efforts. That's exactly the reason why we are partnering with bigger players to really show the true potential of Xen
Maybe you lack the understanding of scale. Xen dev was built and maintained by a relatively small number of people, and despite that, got it working better than most competitor. And you can indeed consider us as a small player right now, but we are roughly doubling each year. Just next year, we'll have more people working on Xen that Citrix itself.
I hope this tells a bit on Xen's future
edit: just few example of driving Xen innovation:
- https://xcp-ng.org/blog/2021/09/14/runx-next-generation-secured-containers/ (in partnership with Stefano from Xilinx)
- https://xcp-ng.org/blog/2021/07/12/dpus-and-the-future-of-virtualization/ (in partnership with Kalray, a CPU manufacturer)
- https://vates.fr/blog/vates-joins-riscv-international/ (porting Xen to RISC-V)
- https://vates.fr/blog/kalray-vates-and-scaleway-alliance/ (alliance with a large Cloud company, Scaleway)
It's a LOT of innovation for a dying project. But well, I'm used to hear that Xen is dead for the last 10 years, so you are not the first to be wrong on this
-
In my honest opinion in depends on the end user. Like i know VM ware does somethings great and other not so much. KVM is the same way as well it all depends what are you most comfortable using. I have dealt with VMware and i have to say it is a little buggy at times. KVM for me is the one i would choose it is so much easier to deal wit as a end user.
-
@olivier said in KVM or VMWare:
Maybe you lack the understanding of scale.
Ok, this is definitely the best one
-
@Francesco-Provino by scale I meant the scale of Xen core developers (ie headcount). It's not that much especially compared to Xen adoption at such… scale
So if you did a lot of things with a relatively small team, this is a pretty nice clue on what could be done with more focus and people! (and yes, Citrix was completely unfocused on Xen, only few years after acquiring it).
But this is clearly changing (the situation, not Citrix
). -
@obsolesce At Microsoft's economy of scale, they make money when people buy new machines.
With the exception of mobile tabletpcs, we get by with used computers. But the security updates of the Win11 will probably mean we buy new desktops in the next year.
-
@francesco-provino Amazon Web Services may have a slight disagreement with you on whether KVM or XEN is suitable for business.
-
@irj If one man IT shops are not embracing InfrastructureAsCode and devOps, then their job will be taken by the cloud. For the rest of us, we see plenty of automation in the same virtualization systems that Amazon uses. XenOrchestra builds some of that in from the get go.
-
@rjt said in KVM or VMWare:
@francesco-provino Amazon Web Services may have a slight disagreement with you on whether KVM or XEN is suitable for business.
LOL
-
@rjt said in KVM or VMWare:
@francesco-provino Amazon Web Services may have a slight disagreement with you on whether KVM or XEN is suitable for business.
KVM and XEN are suitable for the business case of an hyperscaler of course, but the question of @WLS-ITGuy was literally "We're getting ready for our server refresh and along with that our license is up for renewal for VMWare. I am curious to the benefits of KVM over VMWare." -> so they are a small shop already using VMware.
It totally makes no sense to switch from VMware to KVM or Xen-based solutions in his business case.
-
@rjt said in KVM or VMWare:
@francesco-provino Amazon Web Services may have a slight disagreement with you on whether KVM or XEN is suitable for business.
As do every major environment. When you get big, or small, VMware makes little sense. It borders on the absurd. But in the middle tier, huge companies (not SMB) that aren't yet the massive scales of AWS, Google, or the big Wall St. banks, VMware tends to play nice because they have skills and value to automation, but can't write their own solutions. That's VMware's core market. Get smaller than where automation makes sense, which is 95% of businesses, and VMware is in the way of efficient operations instead of aiding it.
The biggest problem is seeing IT as a checkbox, a one size fits all where we just choose a vendor to sell (whether we are paid directly or not) and don't ask about the customer size, needs, use case, workload, etc. and see everything as "this one approach will always work" when, as IT, the one clear "always our job" is to evaluate that need and choose the solution accordingly.
-
@francesco-provino said in KVM or VMWare:
@rjt said in KVM or VMWare:
@francesco-provino Amazon Web Services may have a slight disagreement with you on whether KVM or XEN is suitable for business.
KVM and XEN are suitable for the business case of an hyperscaler of course, but the question of @WLS-ITGuy was literally "We're getting ready for our server refresh and along with that our license is up for renewal for VMWare. I am curious to the benefits of KVM over VMWare." -> so they are a small shop already using VMware.
It totally makes no sense to switch from VMware to KVM or Xen-based solutions in his business case.
I'd say the exact opposite. Now, that he already has VMware gives VMware an edge, where it would never have made sense to put in VMware in the first place, but since it is already there the least effort is continuing with it. But the effort to switch is half in the evaluation, and half in the doing. We move customers off of VMware to KVM regularly and it is fast, easy, and once done, it reduces their risk and cost (mostly by reducing support, but also reducing the need for third party software and, obviously, VMware licensing itself and the biggest cost, consulting hours for VMware licensing.)
In the OP's scenario, VMware is a solid consideration. But does KVM have absolutely crystal clear advantages? Yes 100%. At the OP's scale, VMware is technical debt. The question is only... is the debt too great to bother eliminating? Do they live with a "good enough" solution, or invest in a longer term, easier to support, lower cost, lower risk alternative? The problem is that it's only a little less support, only a little less cost, only a little less risk. So it is a hard comparison.
But the one thing we can guarantee is that no solution is an obvious choice. Not VMware, not KVM. It's a business decision based on a lot of small factors.
The biggest single reason to avoid VMware is the ecosystem around it that is so unhealthy and pushes it and other paid for, licensed, add ons and costly support models very, very strongly without generally any evaluation of the customer's needs. Because VMware is a product sold through the channel, and one with massive profits for the sellers and supporters of it, it creates a system of people and vendors industry wide who push it for their own interests and that's dangerous to customers.
-
@olivier said in KVM or VMWare:
@Francesco-Provino by scale I meant the scale of Xen core developers (ie headcount). It's not that much especially compared to Xen adoption at such… scale
So if you did a lot of things with a relatively small team, this is a pretty nice clue on what could be done with more focus and people! (and yes, Citrix was completely unfocused on Xen, only few years after acquiring it).
But this is clearly changing (the situation, not Citrix
).Something that IT people often don't realize about software engineering is that often the most work, and the best work, is done by small teams. The Mythical Man Month is rarely read in IT circles, only development ones, and the idea that a two man team can easily outpace a 100 man team doesn't seem logical unless you've worked as a developer.
I "recently" had this experience with a customer who trusted a small team, but couldn't understand how a small two man team starting from scratch could compete with a well funded, twenty year old, 65 man team making head to head products. But the two man team had caught up in six months, which was expected on their end.
Partially not dealing with technical debt, and partially by avoiding the network communications effect, and using only 10x people instead of lots of 1x people... all things developers know well but outside of software engineering is almost totally unknown.
VMware actually struggles with how to remain competitive while being so large, rather than the other way around. I'm not saying that they don't overcome it and do a great job. Only that it is a challenge for them that smaller teams don't have. WHen you make software, getting big, makes things hard if you want to keep moving forward. You can do it, but it isn't a "get big and things get easy" situation like in most other industries.
-
@stacksofplates said in KVM or VMWare:
@pete-s said in KVM or VMWare:
It isn't the ability to automate that is the problem. It's the availablility of easy to use tools that is the problem.
Thats the whole point I'm making.
KVM is hard to automate. Not that it's impossible, but the tooling doesn't exist to where you can easily automate like with VMware.
Agreed, and I don't think that that's the point of concern here. The issue at hand should be "does that automation that VMware offers get used by or should be used by the OP?" I believe that the answer is no to being used today and likely no to should it be used. It's a very small deployment. The overhead to the automation, even when you have VMware, is too high. And regardless, even if we agree that it should be used, probably because an MSP/ITSP is brought in to effectively make the environment larger and changing some of the scale discussions, the bigger question would be "will the OP's environment opt to do that anyway?" If that answer is "no", in the practical sense, then the automation point becomes moot.
I "think" we can all agree that VMware has better standard built in automation. And that KVM is completely automatable if you put in the extra, non-standard effort. So if we were considering standard automation then VMware would have an important edge in that area. That point shouldn't be in dispute. We can argue how close KVM gets, while still being behind, sure.
But the key point here, for me, is that I believe based on knowing the environment a bit that that automation is not, and won't be, used if VMware remains.
