harvester VS Flatcar

At Harvester v1.1.2, it seems virtual machines on some AMD platforms cannot detect nested virtualization. This might relate to Harvester issue #3900, but that issue is categorized as a user interface bug only. Besides, I can run virtual machines on my Ryzen 5600G node normally (with SVM, IOMMU, and SR-IOV enabled, while /sys/module/kvm_amd/parameters/nested returns 1).

With this being nowhere documented, I dived into GitHub issues and found #1479. I learned the bootstrap password is admin, which then allowed me to log in.

Or with Hyper-converged infrastructure https://harvesterhci.io/

Have a look at Harvester if you have a unused pc. It can create a k3s cluster in vms automatically. TechnoTim has done a video about it, looks really easy. Also combines with rancher and longhorn for managing cluster a storage.

Im currently using proxmox and I want to what the community's feelings towards Suse Harvester. What are your experiences and is it worth trying out?

This seems like the route, thank you for your response. u/happyColoradoDave pointed me towards harvester which should make VM management easier. Going to go with that to run VMs now.

I assume you mean https://harvesterhci.io/

Like everything, it's context dependent, but wowzers my life has improved so much since I got on board the Flatcar or Bottlerocket train of immutable OS. Flatcar (née CoreOS) does ship with docker but is still mostly a general purpose OS but Bottlerocket is about as "cloud native" as it comes, shipping with kubelet and even the host processes run in containers. For my purposes (being a k8s fanboy) that's just perfect since it's one less bootstrapping step I need to take on my own

Both are Apache 2 and the Flatcar folks are excellent to work with

https://github.com/flatcar/Flatcar#readme

https://github.com/bottlerocket-os#bottlerocket

Shoutout to my favorites, Flatcar https://github.com/flatcar/Flatcar#flatcar-container-linux (Apache 2) and Bottlerocket https://github.com/bottlerocket-os#bottlerocket (Apache 2)

Flatcar grinds my gears in that they have their own cutesy (and ragingly stupidly named) Ignition/Butane/whatever instance provisioning file format when they deprecated the damn-near-standard cloud-init. Bottlerocket also has their own thingy, but at least they go wholesale toward static Kubernetes Pod manifests which are much easier to reason about

Sounds like you're looking for the CoreOS Linux successor FlatCar https://www.flatcar.org/

It's actually based on some ChromeOS update tools under the hood but is a regular Linux distro, just super minimal and designed to run containers.

I guess if you found my comment to be "comically hyperbolic" then replying to mine with a "comically reductionist" is fair game

So, anyway, I actually did dig up a concrete example of my experience with it, and I cannot link to the "Additional information" section but that is both why I think the thing was a mess and also why the Miroservices YT joke resonated: https://github.com/flatcar/Flatcar/issues/220

I think the CoreOS boot strategy was decomposed into a bunch of different executables, each responsible for doing their own little slice of the world. Maybe it drew inspiration from systemd in that way. But, just like my real life experience with microservices, it requires keeping a bunch of different projects and their upgrade paths in ones head, knowing their disparate config formats, and when one of them inevitably has a bug, understanding how to troubleshoot what went wrong with the system as a whole

And, again in trying to be reasonable in this discussion[1] I do also understand why one would opt for the data URI, given how much of the rest of Ignition loads content from URLs. I don't believe cloud-init has that remote content paradigm baked into in nearly the same way, so I hear you about that.

And yes, my belief is that JSON is a data-exchange format from _computer to computer_ and making people write them is a poor DX choice, IN MY OPINION. And, to reiterate, I know that CoreOS's perspective is that it is a computer-to-computer transmission from the transpiler-project-o-the-day to the Ignition binary, but that is predicated on one having access to that transpiler binary in all cases, which is quite different from the problem that cloud-init is trying to solve

fn-1: I'm sorry you got hurt by my "tire fire" outburst, and that evidently derailed this whole interaction, but it was my experience