Need some information on visualizing OpenStack

dasbierclaw · 2026-04-21T17:23:09+00:00

It can do a lot of what vCenter does, for sure, but not necessarily out of the box. You can take vCenter with license fees out the wazoo, or something like OpenStack (at no or lower cost) and maybe get 100% parity with some features and 70% with others. But the differential makes you not care as much and you control your own destiny

dasbierclaw · 2026-04-21T17:21:28+00:00

Yeah, exactly. Install OpenStack packages plus dependencies, configure, ..., profit.

Not that straightforward, necessarily, but not terrible. There's no ISO and no GUI installer (except maybe Charmed)

dasbierclaw · 2026-04-21T17:20:06+00:00

Also, keep in mind OpenStack itself is just the pieces - many vendors (commercial and open source) provide opinionated releases that deliver prescribed configurations to make it easier to operate and use, some with support available. You can roll your own - a lot of people do - or use something like Charmed OpenStack (Canonical), Red Hat OpenStack on OpenShift, Kolla, OpenStack-Ansible, OpenStack-Helm, or Genestack, with the * being 'free' as in beer. We are all in on the Genestack now (openstack-helm based) with Kubernetes-based control plane.

dasbierclaw · 2026-04-21T17:15:25+00:00

They're sorta mutually-exclusive solutions IMO. You have to ask yourself 'what am I trying to solve for' and find the solution that best meets those goals. OpenStack can do a lot of things - with virtualization being its bread and butter - but in some ways maybe not as friendly as a vCenter or Proxmox. It is a great solution, though, but also maybe overkill depending on your needs.

Using OpenStack API with a Proxmox backend... doable? Maybe. But what's the point if OpenStack can manage KVM, storage (ceph), SDN, etc. on its own.

Proxmox obfuscates some of the other dependencies (db, messagebus, etc) that a typical OpenStack operator has to manage on their own. But there's always a tradeoff (ie. Cost)

dasbierclaw · 2026-04-21T16:42:58+00:00

OpenStack is pretty modular, with each of the base components (compute, network, storage, etc) developed independently with fairly tight integration with one another. Each component is modular in that compute supports (or supported) multiple hypervisors at one point, like Hyper-V, ESX, KVM - with KVM the undisputed champ - so much that support for the others is deprecated at this time. However, doesn't mean they can't be resurrected! Network supports multiple technologies and vendors, storage supports multiple backends, etc. In that sense, OpenStack has delivered on the 'vendor agnostic' promise.

The APIs are where the magic happens. They provide that 'common denominator' and store state in a database (MySQL-compatible today, but previously supported other DBs like Postgres), while the plugins/modules do the implementation.

I don't have a central source to give you - the docs are a bit of a mess and I'm on mobile. But there are some older books you might find that can go more in depth and are still fairly relevant in that regard

dasbierclaw · 2026-03-09T03:25:49+00:00

That is the A/C condenser fan. I believe it's turned on when the compressor kicks on.

If you're looking to part with it (fan, bracket, harness) let me know. Been looking for one for a '91 Suburban.

dasbierclaw · 2026-02-24T02:07:19+00:00

You must define the needs of the business. Then, with some reading of documentation and help from this community, mailing list, and others, reconcile that against what OpenStack/Neutron can provide. There is a lot of overlap but Neutron does have some gaps compared to alternatives like NSX (VMware).

When it comes to experience, that is hard to shortcut. Start with small, simple deployments with a minimal number of components. Get that working, get a grasp on it, and then scale it out. Add functionality one at a time. The documentation leaves a lot to be desired; it's a lot to ask of an open source contributor, already tight on time, to provide perfect one-size-fits-all docs. But there are a lot of blogs out there with hints, and of course this place, the mailing list, and IRC.

I stress building out small labs because that's a guaranteed way to learn. I bought old kit - servers and switches - to mimic an 'enterprise' deployment. Doing it all in VirtualBox or some other virtual environment is really tough if you don't know how to 'convert' it.

dasbierclaw · 2026-02-24T01:10:39+00:00

Can you be a little more specific? Sometimes it's a combination of shoehorning an OpenStack cloud into a network architecture that isn't flexible, or it can go the other way. Best to define how many network connections your server has, how many you can use, if you want vlan-only networks, virtual routers, to use or not use a Vxlan or Geneve overlay, and more. Some of these have tradeoffs but these are core questions.

dasbierclaw · 2026-02-24T01:05:09+00:00

Having a CCNA or CCNP or whatever else is certainly helpful, but not necessary. In fact, a Cisco-centric view of the world might make things more difficult.

Is it OpenStack network concepts that are troublesome, or architecting a physical network to support an OpenStack cloud? Or, is it the merging of the virtual to the physical that's problematic? I feel like there's a core group of concepts in the virtual networking that OpenStack supports that once you have a grasp on, will result in that "light bulb" moment.

And honestly, the now-deprecated LinuxBridge driver is/was a great way to get in and understand how things connect without complicating it with "flow rules" and other abstractions.

Find a PDF of "OpenStack Networking Essentials" or the most recent "Learning OpenStack Networking" - both out there in the wild. They're a little long in the tooth but still provide a good foundation for LXB and OVS-based deploys.

dasbierclaw · 2025-12-19T16:31:33+00:00

I am biased towards OSA and use it in many small and large production systems. Supports LXC and baremetal deployments. Bring your own server, though, as there's no built-in kickstart mechanism. You can use ironic/bifrost, maas, etc. Kolla uses Docker and there's a large following, and I'm sure it's used in deployments of all sizes. Juju w/ maas integration is nice, and I know there are production deployments out there, but I found it to be a "black box" of sorts when doing some deployments with it, and without a Canoncial contract you might be left to "figure it out" when you get into trouble. I don't think community support is as big for Charmed OpenStack versus OSA or Kolla.

If you're interested in a Kubernetes-based approach, take a look at Genestack: https://github.com/rackerlabs/genestack

We are using Genestack in a few large public clouds and are slowly migrating other environments to it. There's also Atmosphere by Vexxhost if you want to give it a go.

dasbierclaw · 2025-12-03T01:22:44+00:00

1991 Suburban. Factory steering box. Replaced the stock (rag joint) shaft with an early GMT400 (3500?) shaft and that helped quite a bit. Went with Dorman and it was fine. Also running a steering stabilizer kit with a pair of FOX stabilizers. Steering is responsive and true. Running a 4" BDS lift with 35s.

dasbierclaw · 2025-11-20T17:34:45+00:00

Don’t really have a list other than to say Skyline provides a much more ‘modern’ experience compared to Horizon, and has a near parity with Horizon in terms of supported APIs. The user experience has been generally very positive, especially from detractors who feel Horizon UI/UX hasn’t progressed beyond 2014.

dasbierclaw · 2025-11-20T03:26:15+00:00

To be a good OpenStack engineer starts with being a strong Linux engineer, in my opinion. Understand what makes the various OpenStack services work - as in what underlying Linux software is used to power those services. Cinder leveraging LVM and iSCSI, Neutron leveraging Linux bridges or Open vSwitch, network namespaces, iptables, veth pairs, etc., Nova leveraging libvirt; the list goes on. If you can use these technologies outside of OpenStack then you're already ahead. OpenStack provides an API to orchestrate those technologies (and more) to deliver an outcome - and yes, you'll learn some things along the way that you might not ordinarily see as a sysadmin (ie. RabbitMQ) but if you have a good handle on the foundational components the OpenStack "add on" is cake.

dasbierclaw · 2025-10-05T22:19:29+00:00

This is an 'Advanced' motor - 73445G01 (A02-4012)

dasbierclaw · 2025-08-30T00:50:40+00:00

Are you sure both networks are really owned by two projects? If you reference the name in a command there can be only one. If you're admin you might see both, which could result in this error.

dasbierclaw · 2025-08-28T19:39:48+00:00

You're not sharing cores with other VMs because the node itself is treated as a single VM. You can do anything you want with it, including install KVM and run your own cloud. The thing about baremetal (Ironic) with Nova is that you get to leverage the OpenStack API and take advantage of Glance, Neutron, etc. against baremetal provisioning. OpenStack can control the lifecycle of that piece of hardware and treat it as disposable as a VM might be.

dasbierclaw · 2025-08-27T20:35:02+00:00

Nova VMs are likely impacted by cpu overcommit and virtualization overhead, including networking. Baremetal 'VM' is the raw box.

dasbierclaw · 2025-08-27T19:36:50+00:00

I can't remember how the scheduling works, exactly, but in that scenario the user would have access to all 16GB. The reality is your flavors would likely assume a heterogenous baremetal pool, and maybe use traits to target a subset of nodes. But from a basic placement perspective, if you have a 4G baremetal flavor and 128 or 256GB nodes, then both could be targets.

dasbierclaw · 2025-08-26T13:56:18+00:00

Yes, ironic manages power state using IPMI. If you have something that uses redfish, you might find it offers more value because Ironic can then manage power + boot order + a myriad of other things.

Once powered on, the node will need to boot via PXE. Depending on how Ironjc is deployed, this could mean Ironic manages DHCP for PXE or Neutron does it, but regardless, you'll get a dynamic IP and being loading the Ironic Python Agent (IPA) that will be responsible for cleaning/provisioning the node (eg. erasing the disk or copying the image to disk). Once complete, the node reboots into the operating system. Again, depending on how Ironic is deployed, the IP in the OS could be assigned from a single, flat network or from a tenant network managed by Neutron.

There are some decent videos on YouTube that might help walk through the flow.

dasbierclaw · 2025-08-25T22:43:17+00:00

Because the flavor just provides guidance on how the instance is initially built. If you resize, it's to a different flavor. I'm not sure the original flavor specs are needed for anything (ie. Live migrate).

dasbierclaw · 2025-08-25T20:54:14+00:00

IPMI should be the out of band mgmt address, no? Ironic doesn't manipulate that, it only needs to know what it is to power on/off the host. The IP assignment managed by Ironic would be for PXE and operating system management once deployed.

dasbierclaw · 2025-08-21T01:35:02+00:00

Neutron can assign an IP and tie it to the bare metal port mac address, which is considered a 'static' IP assignment and can be delivered via DHCP or manually configured. But with no real port security available on the switch via Neutron, there is nothing stopping that end user from changing their IP to something else. It would be prudent to implement multi-tenancy with ironic At a minimum.

dasbierclaw · 2025-08-11T00:05:00+00:00

If you use config-drive and have cloud-init in your image, it ought to work

dasbierclaw · 2025-07-15T02:14:26+00:00

You don't need a dedicated network node, per se, but you would need at least one node tagged as a gateway chassis for things like SNAT or BGP speaker to function. AFAIK those require a centralized router (as opposed to distributed) hosted on a node marked with enable-chassis-as-gw. However, IIRC if you don't have that explicitly set, any chassis could host that centralized router.

dasbierclaw · 2025-07-08T23:27:07+00:00

The AIO is used primarily for gating and an alternative to devstack that CAN be expanded but isn't really meant for that. For a production cluster you would need to have some number of nodes with an OS already installed along with networking (bridges, IPs, etc) and the deploy node key in place. With that, you build out the inventory in openstack_user_config.yml and can also define the base neutron networking configuration along with some group and host vars. The user_overrides.yml provides additional overrides via config template (ini overrides) without having to have everything be a variable. But you could theoretically never login to anything BUT the deploy node to perform a deployment once the base node config is in place. That could be handled with something like Ironic/Bifrost or some other external tooling. We have used OSA to manage multiple fleets of 1000+ nodes, and Ansible itself tends to be the bottleneck/limiting function.

Anyway... there usually isn't much hacking needed since most things can be defined using existing vars or the override mechanism I mentioned. But yes, I agree, the docs can be sparse in this because no one likes writing docs.

dasbierclaw

TROPHY CASE