Hacker News Reader

Comment by rwmj | Hacker News Reader

We (Red Hat) are doing great business moving customers off VMware. 20,000 VMs is not an unusual amount for our larger customers. I did a 5 min lightning talk in summer about this: https://pretalx.com/devconf-cz-2024/talk/SN93LG/

View on HN

It is funny because my former company was trying to move out of vmware even before the broadcome aquisition and the local sales rep pretty much told us RHEV was a dead project but at the time openshift virt wasn't ready yet.

In the end I left before broadcom bought vmware but the status at the time was "let's wait a bit more".

I don't agree with the deprecation of RHV since it's very closely modelled on VMware vCenter in terms of the concepts and user interface. So it's ideal for ex-VMware admins. But here we are. Containers & Kubernetes are more buzzword-compliant than virtual machines.

Basically, RHEV as a VMware takeout project never gained a lot of traction. With the general industry shift towards containers and Kubernetes plus the Broadcom acquisition, kubevirt in combination with a much more mature OpenShift is a lot more interesting.

So working in the MSP space providing IT support to clients, our VMs are 90% mostly Windows Servers.

Due to the applications, our clients use + AD + File share. Explain how (excuse the French) the fuck Kubernetes and OpenShift helps here.

Thanks xoxo

Red Hat (obviously) and Microsoft (increasingly) aren't all that focused on Windows as an operating system on the server. And the desktop, in general, is about the browser with some relatively niche exceptions.

Probably, outside of VMware, you run Xen for Windows servers.

Okay, but I thought the whole point of VMs was to be OS agnostic? :)

I should be able to run all OS on a VM platform. :) Right? :) What is the friggin point.

Xen is an option but is it viable for big datacentre deployments?

There are always transition costs from the point of view of migration/management at least. Applies to one version of Linux to another as well.

The strategic jump is probably to Kubernetes/OpenShift/kubevirt but there are probably intermediate steps like Xen one could make instead off VMware.

A browser as a desktop replacement is something for management roles. Although if you only need a browser for work, the company should check if they need the role in the first place.

Producing industry isn't a niche exception.

Umm, I think you are just in a bit of a bubble with regards to a lot of jobs, there are tons of people who do useful work that just use a browser. Off the top of my head, just in my company the customer service and shipping staff are entirely browser based.

Finance is mostly browser based in many orgs, and for people who are all-in on Google docs it's 100% browser based. Service companies such as contractors seem to have transitioned to cloud platforms accessed off of a browser or Android app that is essentially just a webview.

Ironically, tech companies are behind the curve in regards to having a higher proportion of users like devs and designers that need applications that aren't browser based.

I use desktop apps for certain things--mostly multimedia and dev. But I spend the majority of my time in a browser. I mostly don't even use my office because the 10-year old laptop in my kitchen works fine for web-based work, don't need a second monitor for many tasks, and the room is lighter and airier.

My comment was a bit inflammatory, of course it isn't useless work, but that stems from consultants that often naively suggest we should move to the cloud. But that isn't really sound advice and just far from reality. As I said, this is producing industry, so perhaps an edge case for better of worse.

Our R&D and production probably cannot ever move completely to the browser. Security restrictions of browsers are focused on being safe on the net, so interactivity is limited and overall it is often impractical.

And since we have at least hybrid environments, we often compare desktop usage with purely cloud approaches and the desktop seem to mostly win for productivity. And I bet this would be the case for many other companies too.

Sure, if you are purely service based, it can work. But even our customer service has a workshops with numerous devices measuring materials in all kinds of way. You cannot really connect them to a browser. Or you could, but then it is extreme impractical again.

Or logistics. Scanning pallets, registering wares, nothing here is browser based. It really seems to be the word, excel crowd that can do it and maybe your erp is a cloud solution.

I do software development. Theoretically I could develop in the cloud too for the most part but I would also severely hate it. And even if I restrict myself to the Microsoft part, it also is a bit unreliable.

Odd way of phrasing your question but my general thought is your <10 server, no IT staff MSP customers aren't the focus of this conversation or most of the userbase here.

vmware attracted exactly the companies who were not necessarily shifting, or not shifting everything to containers and kubernetes.

There are still loads of companies who still manage pets.

Looks like that tool typically targets KVM as a source. My understanding is that Red Hat's own virtualization platform is transitioning from RHEV to OpenShift. If that is true, are you actively moving customers from vmware to OpenShift via Kubevirt?

Upstream, virt-v2v supports conversions from VMware to either oVirt (RHV) or KubeVirt (OSV), and we don't plan to drop the oVirt support any time soon.

However Red Hat now only supports conversions to OSV, since RHV was deprecated (sadly).

The biggest problem is oVirt itself has not proven to be a very sustainable open source project. If oVirt dies, we'll likely remove support in v2v. (There's a great start up opportunity here, for a dull but money-making company that productizes oVirt again.)

To move VMs from RHV to OSV you can just copy the disk image since they already should have virtio drivers, qemu guest agent, and be able to boot on any qemu/KVM-based platform. I believe there's some automation for that, but it doesn't involve virt-v2v.

Thank you for taking the time to explain. I was honestly a little shocked to hear about RH moving away from RHV, but glad to hear there is some interoperability between some of these tools.

There never was a lot of interest in RHV as a like-to-like VMware alternative. But, when I left, there was quite a lot of interest (especially post-Broadcom acquisition) in a Kubernetes/cloud-native friendly VM alternative to VMware. And, yes, there are various migration tools though I was not involved in the details.

> There never was a lot of interest in RHV as a like-to-like VMware alternative

That is because it was before Broadcom lit VMware on fire. Nowadays everyone is looking for a like for like VMware alternative.

> Kubernetes/cloud-native friendly VM alternative to VMware

Cloud-native and VMs for the people used to the VMware world are antithetical. Overwhelmingly we're talking about carefully managed pets, which is exactly the opposite of cloud-native.

I agree, hence my idea about resurrecting oVirt (see up thread). Red Hat are all-in on Kubernetes, which is the wrong model for pet VMs, but a better model for gitops stuff.

I'd argue it's still essentially backward facing. Yes. There are buyers who would essentially like a cheaper VMware clone today. But I'm not at all convinced that's a good business model for a company like Red Hat to invest in going forward.

> There are buyers who would essentially like a cheaper VMware clone today. But I'm not at all convinced that's a good business model for a company like Red Hat to invest in going forward.

Yes, they're buyers stuck in the past. If RH can bring them on and take them on a modernisation journey, it could be very lucrative (even if very time consuming).

Thank you for the explanation

Reply on news.ycombinator.com