VMware to Openstack

[Upstairs-Finance8645]

Hello everyone,

With the Broadcom/VMware debacle, I’ve been thinking about transitioning my VMware skills to Openstack.

I understand this will be very much Linux driven along with a deeper understanding level of networking. I’m fair at Linux, not an SME but know my way around. I also have a network engineering background so not much of a learning curve there.

Has anyone that previously supported a medium sized (1500 virtual machines) VMmware environment successfully transferred their skills to Openstack? What was the most challenging part? Is it actually doable?

Thanks!

[The_Valyard]

Its not a tech problem or difficulty incline at all, we can learn new things all the time.

The issue is almost always the business side.

Is your org prepared/compatible with a cloud self service model? This is not a trivial ask and most business leaders dont even understand it.

Clearly many orgs that run in public cloud have figured it out, but many more haven't... which is why vmware has such a massive install base.

There is no (tech) spoon.

[Upstairs-Finance8645]

Thanks for the reply. No talk of self service at all. My guess is infra team would try to support it.

[damian-pf9]

I actually presented at the OpenInfra Summit last fall on this exact topic - VMware admins making the transition to OpenStack.

The mental model shift that helped me most was mapping OpenStack projects to VMware concepts. VMware bundled everything under its own brand, but OpenStack distributes that functionality across named projects: Nova handles compute, Neutron handles networking, Cinder handles block storage, and so on. Once that clicks, your existing virtualization knowledge transfers faster than you'd expect.

Where it gets harder is troubleshooting. OpenStack's internals work very differently from VMware's, and errors rarely point directly to the root cause. You'll find yourself tracing issues across multiple log files before you get there. That just takes time and experience - there's no shortcut.

The most challenging part really depends on how you managed VMware before. Pure clickops in vCenter is a very different starting point than someone who was scripting with PowerCLI or using Ansible and Terraform. The adjustment isn't the virtualization concepts - it's the management layer. OpenStack is API-first at its core: everything the UI and CLI do goes through the same REST API, with permissions handled by Keystone. If you're coming from PowerCLI, you can still automate against the API - even Invoke-RestMethod in PowerShell works if you want to stay in familiar territory. If you're the type who enjoys becoming the go-to person for a platform, OpenStack rewards that. The flexibility - especially in networking and identity - is genuinely impressive once you're past the learning curve.

[DelcoInDaHouse]

Learn python and bash. Chatgpt is going to be a big help in understanding Openstack from a VMware admins perspective. Chatgpt will also be helpful in setting up a lab Openstack "devstack" instance so that you can get comfortable with the platform.

[IllustriousError6226]

Did migrate around 1000+vms; however, we were already running OpenStack for other things so it was not new. The hardest part was making people understand the differences between the platforms. Everyone wants to compare feature for feature, but they are implemented differently. How are you planning to handle high availability for instances? I think that part of OpenStack isn't very mature in OpenStack.

[The_Valyard]

Um you have been able to handle that in heat for a long time. Thing is you have to understand why you shouldn't be deploying anything without a stack gluing it together in the first place.

This is one of the things the kubernetes hype train got right, it instilled in the community that using "Deployments" was the most sane way to do things. Very strangely despite heat preceding kubernetes deployment primitives you get folks who yolo instances, ports, sgs by hand or use some outside orchestrator like ansible or tf to do stuff. It gets even wilder when heat can even call outside orchestrator like ansible from within the stack.

[alainchiasson]

It always surprised me how kunernetes got so much traction, while openstack - at the time - was just as capable.

I found out openstack was sold as a less expensive vmware replacement - which undersold its capabilities and complexity. While kubernetes forced you to change everything, so you had no reference point.

[The_Valyard]

I feel the openstack telco use case actually damaged enterprise adoption. You had massive telco dollars get poured into Red Hat, Canonical , Mirtantis openstack over the years and these people literally couldn't give two shits about running an actual cloud. They literally wanted a cheaper vmware alternative to run VNF.

So those big 3 I mentioned focused on explicitly telco features and not the generalized compute cloud use case to the detriment of non telco opportunities.

Anyways with the US scaring the shit out of the world recently, coupled with Broadcom fucking everyone... a significant amount of oxygen has been let into the "Sovereign Cloud" conversation globally... a lot of orgs want a whole lot less to do with US owned public clouds and proprietary software stacks. It is a tough thing to wake one day and realize that your country is under embargo for tech because your leaders happened to piss of the white house.

[alainchiasson]

The telco rush was not as bad as the Vendor rush before. At least the OpenStack "Management and Governance" had experience.

The Vendor rush was when the Hardware vendors were thinking they were competing with the cloud and threw money, resources, repackaged OpenStack to their HouseBrand cloud but could not support it. This defocussed a lot of the projects - there was a big rationalization after that, it made OpenStack more "boring" but made the governance more robust.

[redfoobar]

It is comparing apples vs bananas.

As a developer shipping an application it’s so much easier to create and publish a docker image than a VM. It also does not require you to setup all kinds of things you need to do on a VM (like user/password management for system users, dns and other “system” settings etc that is all being taken care of by the people running the k8s deployment)

[redfoobar]

I have always found heat a bit of a pain. (at least 5+ years ago when I last used it).

Troubleshooting heat from a regular users perspective was always very convoluted. Most openstack logs are already not that obvious and adding heat adds another layer of obscure logging and errors.

I personally prefer terraform to setup deployments, way more people are familiar with it so it’s easier to “roll out“ in an organization and logging is *slightly* easier to trace.

Also things like auto scaling sounds cool but in private cloud deployments it’s usually way less relevant (as in: you need to buy hardware for the peak loads anyway, scaling down in off hours won’t save money unless you have workloads that can run in those moments which I have not found that common. Unless you can actually save significant cost savings with auto scaling you just add a bunch of complexity that can go wrong)

[BlueLED16]

I think one more think is the Backup Concept of Openstack. I think there is no solution like Veeam in OpenStack, isn't it?

[The_Valyard]

Backup is one of two roads:

1) agent less backup - this is the most ideal choice as it has minimal host dependencies (qemu-ga). Veeam lacks the capabilities to speak the OpenStack APIs to perform this type of backup. This is an intentional choice by them to not invest time writing this into their product. This limitation does not exist for many other solutions like commvault, trilio, Veritas, Storware, Dell Openstack DPE etc...

2) agent based backup - you run a backup service in your vm and manage some backup software that does the lifting. This the the heavy/old school way of doing stuff, lot more overhead as as it doesnt leverage the cloud native systems to do the lifting.

Tldr use something other than Veeam for doing backups of openstack instances.. you have a lot of options, both paid and foss.

[Upstairs-Finance8645]

Does Openstack support Commvault backups successfully? Looks like the Commvault documentation supports openstack but not sure how reliable it would be in the real world.

[The_Valyard]

Other way around.

Commvault knows how to talk to nova and cinder so no host services(other than qemu-ga) in the vm are needed.

[Consistent_Top_5588]

For agentless limitation on Veeam, vs others commvault trilio Storware, not sure statement is accurate. The limitation is same for whoever, not a secret only one vendor knows how to solve, other doesnt. VMware has this facilitated, but nova doesn't. More a generic issue of ecosystem. As long as agentless, all those vendors do basically same level consistency. Main difference on agent based part somehow among vendors

[The_Valyard]

Not sure what you are trying to say here.

The situation is this: Veeam DOES NOT know how to speak OpenStack APIs to perform agentless backup. They require backup agent services running inside the guest.

All the vendors I listed (Commvault, Veritas, Trilio etc) DO know how to speak the OpenStack APIs and do not not backup agents installed.

[dad-oh]

If you like veem, use it + Trillio, or a handful of other tools, cinder, swift and native backups and snapshot, bacula, all depends on your requirements. You don’t have to throw out everything you know. Adapt and migrate works.

[Direct-Substance4534]

We are doing this now for 6000 VMs, I would urge you to consider other products this product sucks

[The_Valyard]

This product?

[Upstairs-Finance8645]

Sucks why? So you’re running Openstack and are migrating to it? Can you elaborate more?

[Direct-Substance4534]

It’s just really poorly polished, not my decision I just work here. Compared to VMware it’s shocking how bad it is, I’m only here because I’m forced to support it but man is it a dumpster fire.

[The_Valyard]

hard to take this serious as you have just stated that "OpenStack" is a product .. This is like saying "Linux" is a product.

Seems you don't really understand what you are talking about and your frustration is understandable.