[HN Gopher] Red Hat Woos VMware Shops with OpenShift Virtualizat...
___________________________________________________________________
Red Hat Woos VMware Shops with OpenShift Virtualization Engine
Author : rbanffy
Score : 102 points
Date : 2025-01-16 14:45 UTC (8 hours ago)
(HTM) web link (www.nextplatform.com)
(TXT) w3m dump (www.nextplatform.com)
| lenerdenator wrote:
| What're the FLOSS technologies underlying OpenShift? Sounds like
| KVM?
| samcat116 wrote:
| Probably kubevirt if I had to guess (which would then use KVM
| under the hood)
| houseofzeus wrote:
| Yes you are correct, it is kubevirt and leveraging KVM as the
| hypervisor coupled with the QEMU/Libvirt userspace pieces.
| natebc wrote:
| Openshift is Kubernetes+.
|
| Openshift Virtualization Engine is kubevirt (aka kvm/libvirt).
| lyarwood wrote:
| https://github.com/kubevirt specifically for OpenShift
| Virtualization
| whalesalad wrote:
| everything ultimately boils down to kvm or qemu, usually
| antithesis-nl wrote:
| Well, the Enterprise-hypervisor market is certainly _wide_ open
| right now, due to Broadcom turning the financial screws on VMware
| customers _hard_. There are, broadly, two categories of
| potentially-profitable VMware customers up for grabs:
|
| -Large enterprises that previously purchased hardware-with-
| accompanying-VMware-licenses from OEMs like Dell-EMC: Broadcom
| refused to even honor pre-acquisition license keys from these
| sources, leaving many private data centers in the lurch, unless
| they paid a _huge_ premium for a new Broadcom-originated annual
| subscription (whereas the original key was one-off)
|
| -Service providers with an ongoing "small-percentage-of revenue
| per year, payable in arrears" agreement, that were suddenly
| forced into a "hard vCPU and vRAM limit" subscription, payable
| for at least 2 years upfront.
|
| However, the magic word for both customer segments is "vMotion",
| i.e. live-migration of VMs across disparate storage. No OSS
| and/or commercial (including Hyper-V) solution is able to truly
| match what VMware could (and can, at the right price) do in that
| space...
| zellyn wrote:
| I think Oxide's stuff does live migration, but I don't know how
| well it runs on non-Oxide hardware.
| antithesis-nl wrote:
| As far as I can tell, Oxide is all about compute, not storage
| -- i.e., as long as you can guarantee a stable storage layer,
| your Oxide racks will be fine.
|
| VMware used to go a bit further, in that they allowed your
| compute nodes to fail _and /or_ your storage nodes to fail,
| without adverse effects.
|
| If Oxide can do that, out-of-the-box, right-now, they'll be
| having a field day. Otherwise, my reservations about Oxide's
| business model remain...
| zellyn wrote:
| I _think_ their storage layer is fault tolerant. Not sure
| though. Hopefully one of them will weigh in here.
| steveklabnik wrote:
| This is not my area of expertise, so I'll quote from our
| website: https://oxide.computer/product/storage
|
| The storage service uses OpenZFS for all data storage.
| This marries Oxide's distributed data storage and multi-
| node failure resiliency with the dependability and
| efficiency OpenZFS has earned in its 20 years of running
| demanding workloads.
|
| The Oxide control plane monitors performance metrics as
| another early signal of component failure. As sleds and
| SSDs are rotated in and out, the Oxide control plane
| migrates storage regions to ensure the appropriate
| redundancy.
|
| OpenZFS checksums and scrubs all data for early failure
| detection. Virtual disks constantly validate the
| integrity of your data, correcting failures as soon as
| they are discovered.
| zellyn wrote:
| I figured ZFS would do the low-level redundancy, but I
| was under the impression that Crucible does the higher-
| level stuff, and I don't know much about it.
| houseofzeus wrote:
| I think most of these solutions including OpenShift
| Virtualization, Hyper-V, Proxmox, etc. do live migration.
| What the previous post is talking about is some of the more
| advanced VMware live migration features like storage live
| migration and cross-cluster live migration and some of the
| automations layered over the top of them.
| wesapien wrote:
| vMotion is about host failure. If a blade server dies, the vms
| can be spun up on another blade. Storage is same.
| antithesis-nl wrote:
| > vMotion is about host failure
|
| No? It's also about load balancing and draining
| compute/storage resources in preparation for maintenance.
|
| Most pertinently: as long as your alternative doesn't cover
| _any_ vMotion use-cases, customers will remain 'in talks'
| with Broadcom...
| toredash wrote:
| Fun that people -still- don't understand the feature set
| that VMware provides.
|
| He/She is thinking about VMware Fault Tolerance
| blown_gasket wrote:
| You're thinking of high-availability, which registers the vmx
| file of the VM to a physical server that isn't dead, then
| powers the VM back on. Whereas vMotion is either a cold or
| live-migration of the VM + memory state (if the VM is powered
| down, there is no memory state to migrate).
| trebligdivad wrote:
| libvirt+qemu can do live migration across disparate storage; I
| know quite a lot of people want to use it. I'm curious in which
| ways you find the vMotion stuff does well with that.
| noja wrote:
| What can VMware do in this vmotion space?
|
| The docs says open source can do a live migration, see
| https://www.linux-kvm.org/page/Migration and
| https://docs.redhat.com/en/documentation/red_hat_enterprise_...
| mjevans wrote:
| Vaguely like MS Active Directory vs Kerberos. The really big
| thing 'vmotion' provides is 'things just work' vs flexibility
| of options but more effort required.
| SteveNuts wrote:
| Hashicorp has some Nomad drivers for Qemu and a beta version
| that uses libvirt. However it's fairly immature and lacks a lot
| of features they would need to be competitive there.
|
| Since IBM already has OpenShift I'm not sure how much time and
| effort they want to put into Nomad virtualization, but I'd love
| it as an alternative to Kubernetes.
| tart-lemonade wrote:
| Third is academia. Even with a marginal academic discount, it
| doesn't come close to offsetting the price hikes. When the
| choice is between slashing personnel budget and minimizing the
| usage of/completely migrating away from VMware before the next
| renewal, there's really no choice in the matter, especially
| with the difficulty of firing employees.
| lenerdenator wrote:
| > However, the magic word for both customer segments is
| "vMotion", i.e. live-migration of VMs across disparate storage.
| No OSS and/or commercial (including Hyper-V) solution is able
| to truly match what VMware could (and can, at the right price)
| do in that space...
|
| Someone's gonna start working on that soon. Necessity is the
| mother of invention.
|
| To me, this will be the UNIX wars moment for virtualization.
|
| Originally, UNIX was something AT&T/Bell Labs mainly used for
| their own purposes. Then people wanted to use it for
| themselves. AT&T cooked up some insane price (like $20k _in
| 1980s money_ ) for the license for System V. That competed with
| the BSDs for a while. Then, some nerd in a college office in
| Finland contributed his kernel to the GNU project. The rest is
| history.
|
| UNIX itself is somewhat of a niche today, with the vast
| majority of former use cases absorbed by GNU/Linux.
|
| This feels like an effort by Broadcom to suck up _all_ of the
| money in the VMWare customer base, thinking it 's too much of a
| pain in the ass to migrate off of their wares. In some
| circumstances, they're not wrong, but there's going to be teams
| at companies talking about how to show VMWare the door
| permanently as a result of this.
|
| Whether Broadcom is right that they can turn a profit on the
| acquisition with the remaining install base remains to be seen.
| pjmlp wrote:
| I consider UNIX/POSIX becoming niche, including GNU/Linux,
| for the so called cloud native workloads.
|
| The large majority of managed languages being used in such
| scenarios, compiled to native or VM based, have rich
| ecosystems that abstract the underlying platform.
|
| Moreso, if going deep into serverless, chiseled containers,
| unikernel style, or similar technologies.
|
| Naturally there is still plenty of room for traditional UNIX
| style workloads.
| gerdesj wrote:
| >However, the magic word for both customer segments is
| "vMotion", ... . No OSS and/or commercial (including Hyper-V)
| solution is able to truly match what VMware could (and can, at
| the right price) do in that space...
|
| Storage vMotion requires a hefty license (as does DVS and the
| other useful things, such as containers). Proxmox does it all
| out of the box at a very reasonable price point.
|
| Hell, VMware wont even let you use LLDP until your pissing
| money out of all orifices. You get CDP only for "free".
|
| After 20+ years of being a VMware fanboi I am migrating all my
| customers to Proxmox. I've had enough.
| zozbot234 wrote:
| > Proxmox does it all out of the box at a very reasonable
| price point.
|
| Live migration of containers via the CRIU featureset
| (checkpoint+restore in userspace, which is now part of the
| mainline Linux kernel) is also an interesting theoretical
| possibility - AIUI the Kubernetes folks are at least thinking
| about supporting it. (Live migration fits remarkably well
| with containers since it requires comprehensive namespacing
| of all system resources - abstracting away from any
| dependence on the local machine - which is also how
| containerization works to begin with.)
| mvdwoord wrote:
| I would think another issue for a lot of existing large VMware
| customers is NSX (incl. dynamic firewalling), orchestration
| (vRA/vRO), vROPS, and the gazillion integrations that have been
| built with tight coupling at both ends. Swapping that out is
| not an easy task, and the "digital transformations" some of the
| available products are banking on take a lot of time in real
| life.
| UltraSane wrote:
| " Broadcom refused to even honor pre-acquisition license keys
| from these sources, leaving many private data centers in the
| lurch"
|
| How is this not contract violation?
| bigstrat2003 wrote:
| That was my question as well. This seems blatantly illegal.
| jandrese wrote:
| The courts will make that decision in 5 years or so, but it
| doesn't help people who need their stuff working today.
| andrewf wrote:
| AT&T sued them. https://www.ciodive.com/news/broadcom-att-
| vmware-settlement-...
| plagiarist wrote:
| Sometimes it turns out that contract law only applies to the
| poorer of the parties engaged in a contract.
| oneplane wrote:
| Xen (and XenServer and XCP and the Citrix banded stuff) have
| been able to live migrate VMs for a really long time.
| Definitely not something special to VMWare.
|
| Realistically, all the legacy workloads (those that are
| singletons and can't be load-balanced, need an active GUI
| session etc) are going to to be problems forever, even if you
| keep VMWare around.
| whalesalad wrote:
| If I were building a datacenter today I would go with proxmox.
| It's "just debian" under the hood and can be customized and
| controlled a multitude of ways (UI, CLI on the box, Terraform,
| API, etc)
| throw0101c wrote:
| > _If I were building a datacenter today I would go with
| proxmox._
|
| I use Proxmox as well in a small-ish deployment, but have also
| heard good things with Xcp-ng.
|
| At a previous job used OpenStack.
| NexRebular wrote:
| Or if you'd like to help preventing linux monoculturalization
| of datacenters, MNX Triton or vanilla SmartOS are very good
| options too.
| whalesalad wrote:
| The cool thing about proxmox is that it is - again - "just
| debian" so there is really no vendor lock-in. Yes they do
| have commercial support/update subscriptions but the
| community offering is open (https://github.com/proxmox). So I
| do not worry too much about lock-in or monoculturalization.
| At the end of the day it is a wrapper around fundamental
| components of Linux. They do not have any proprietary secret
| sauce that would F you down the road.
|
| Correction I see now that the projects you reference are
| Solaris based. I am down with that cause too - but if you are
| a BSD/Solaris shop expect to do a lot of things on your own.
| The linux virtualization space is substantially larger (not
| necessarily suggesting it is better...)
| jclulow wrote:
| As an aside: Solaris is something you can buy from Oracle,
| which they forked from OpenSolaris 15 years ago. SmartOS is
| a distribution of illumos, which also forked from the same
| code 15 years ago. They have since diverged, in some areas
| dramatically, so we (the illumos community) don't bill
| ourselves as being Solaris based.
| yjftsjthsd-h wrote:
| My impression, strengthened by
| https://wiki.smartos.org/managing-instances-with-
| vmamd/#usin... , is that SmartOS preferentially operates at
| the per-host scale, which is probably a disadvantage in a
| datacenter setting. (I don't know enough about MNX Triton to
| comment)
| zozbot234 wrote:
| Doesn't Proxmox use a separate kernel package compared to
| Debian? That's kinda annoying because it ends up making the
| distro a 'Frankendebian' at best. Even using an up-to-date
| kernel from the stable backports repositories is a lot better
| than that.
| brirec wrote:
| They use a slightly modified Ubuntu kernel
| (https://github.com/proxmox/pve-kernel), with things like ZFS
| added. They also really are good about using proper Debian
| tooling, and so their kernel doesn't cause any weird
| dependency issues.
|
| Right now they install proxmox-kerne-6.8.12-6 by default
| (using pseudo-packages called proxmox-default-kernel and
| proxmox-kernel-6.8 pointing at it), and offer proxmox-
| kernel-6.11.0-2 as an opt-in package (by installing proxmox-
| kernel-6.11)
|
| I've been using the latest opt-in kernels on all of my
| Proxmox nodes for a few years now, and I've never had any
| issues at all with that myself.
| zozbot234 wrote:
| > things like ZFS added
|
| That's a big gotcha - ZFS is non-free so of course it
| cannot be part of Debian proper. Hopefully we'll get
| feature parity via Btrfs or Bcachefs at some point in the
| future.
| Lariscus wrote:
| Thats incorrect, it is free software but incompatible
| with the GPL.
| yjftsjthsd-h wrote:
| > ZFS is non-free so of course it cannot be part of
| Debian proper
|
| ZFS is under the CDDL which is a perfectly good free and
| open-source software license, just some people view it as
| incompatible with GPL (IANAL, but this is apparently
| somewhat controversial; see the wikipedia page) so Debian
| doesn't distribute ZFS .ko files for Linux in binary
| form. They do, however, have an official package for
| it[1], just using DKMS to compile it locally.
|
| [0] https://en.wikipedia.org/wiki/Common_Development_and_
| Distrib...
|
| [1] https://packages.debian.org/sid/zfs-dkms
| Maskawanian wrote:
| It certainly has an optimized kernel for its use case. I
| believe it also includes ZFS by default. I wouldn't be
| surprised if the Proxmox developers would prefer to upstream
| these defaults, but they likely would introduce regressions
| for the common use case that Debian optimizes for.
|
| Ultimately, I use Proxmox as a hardware hypervisor only, so I
| don't mind that it uses its own kernel. Everything I run is
| in its own VM, with its own kernel that is setup the way I
| want.
| samcat116 wrote:
| I'd be worried how proxmox would scale past a few racks. The
| bones are all good, but I'm not sure how much scale testing
| their API layer has had.
| INTPenis wrote:
| I'm using it now, even paying for it, and it works very well
| but I only have one wish. That they could distribute an image
| based distro, or a slimmed down appliance ISO. It just seems
| unnecessary to have an actual OS on each host. Specially since
| I've been impressed by Talos and Openshift for a while.
| whalesalad wrote:
| https://pve.proxmox.com/wiki/Linux_Container
| stego-tech wrote:
| They've been hammering us pretty hard, especially some folks in
| the leadership chain who worked with them before. While I have no
| direct beef with the product, the reality is that our Enterprise
| workload (and in fact, _most_ Enterprise IT workloads in my
| experience) are VM-first, not container-first.
|
| My research conclusion at the time was that, while OpenShift is a
| great product worthy of consideration, it really only shines in
| organizations that are heavily invested in microservices or
| Kubernetes. If you (or more specifically, your vendors) haven't
| migrated into that state, it's not worth it compared to a RHEL
| server license and their KVM+Cockpit solution for bog standard
| VMs.
| woleium wrote:
| or proxmox.. i was going to say for small shops, but i have
| heard of some larger deployments recently.
| more_corn wrote:
| Moving off VMware (yay!) Onto open shift (crap.)
| breakingcups wrote:
| Red Hat just hit us with 300% price increases for OpenShift
| across the board right after we went live in production after a
| little over a year of implementation. The entire org is very,
| very unhappy about it.
| woleium wrote:
| An IBM by any other name would smell the same?
___________________________________________________________________
(page generated 2025-01-16 23:01 UTC)