Hacker News Reader

Comment by siliconc0w | Hacker News Reader

I've used Proxmox for home-lab stuff but anyone know how viable it is for SMB?

It's overkill for small business. Makes more sense at "medium". Small business does fine with plain old QEMU/KVM and the open source tools: virt-install/manager, etc.

Understand that I routinely manage QEMU machine configs by hand, because it's trivial. Perhaps I lack perspective.

How many VMs you consider to be "medium"?

VM count is a poor metric. Spawning lots of VMs is a matter of looping over virt-install or "virsh create" or what have you. The real bottleneck is storage: how are you solving that such that you can migrate VMs around to service things. Once you get past a couple (~2) network storage arrays you're probably into "medium."

But I'll answer your question directly, nonetheless. At ~45 VMs, I consider the system "small."

Understand you're going to need intimate familiarity with the extant tools. Not that it's hard or anything. It's not point/click Proxmox style, though.

You've got this a little backwards. QEMU/KVM is too console-centric for small businesses. Proxmox's appeal is that it has an easy GUI web interface that hobbyists or "de-facto IT department persons" can work with.

It may be overkill in terms of features but it's a free as in beer tool that novices can install and run with quickly without much of a learning curve.

Ok, as I said, I may lack perspective. I version control VM configs and script VM deployments, and manage a herd of containers with ansible. We're talking about simple minded code monkey stuff here: the real work is elsewhere.

For sure, and I think your way is probably superior overall.

There are just a lot of people where as soon as you say “code” or “text editor” they are out.

My proxmox stack is manually managed in the management GUI, but my Linux VMs within that setup are all managed with a Chef server that runs on one of the VMs. (I would say I only chose Chef because I use it at work and I have recent familiarity and figured I could learn more about it)

Basically I do the standard graphical Debian installer and then run a bootstrap script that registers each system as a client.

The next thing I’d like to do is figure out cloud-init with Proxmox so that I don’t have to do that manual installation process anymore.

This setup works okay for me as-is since I only have about 5 VMs at a time, it’s just a hobbyist setup.

> Basically I do the standard graphical Debian installer and then run a bootstrap script that registers each system as a client.

Great approach. Might try that.

> The next thing I’d like to do is figure out cloud-init with Proxmox so that I don’t have to do that manual installation process anymore.

Yeah. cloud-init...

The only advice I have there is: use only core cloud-init capabilities -- the stuff that's been around for years, works everywhere and is unlikely to change in subtle ways -- and factor everything else into a shell script that does the rest, which you invoke from cloud-init.

Oh yeah, for cloud init I only need write_files, path, and runcmd. But also it can all just be runcmd.

For chef you put a client validator key in a specific location along with a first boot json file that has details about the client’s policy name and group.

After that it’s pretty much just installing the chef client and running it.

On the contrary, I haven't manually touched a QEMU/KVM config in a few years because of the above tooling and Proxmox. I think there was a handful of times I needed to add manual additions.

Well, I got past being dazzled by QEMU machine config files years ago. They're actually rather simple. Once you grasp dealing with QEMU at that level its a short, and possibly dubious step, to just CLI-ing everything. The GUI tools are efficient for picking up on new capabilities as QEMU/KVM evolves with time.

I've been known to just start VMs from the CLI directly, for experimental purposes. The tooling everyone uses (Proxmox, virt-*, etc.) obscures the fact that spawning a VM is just a command with a bunch of switches. I suppose that familiarity for me came from using QEMU to emulate other archs on x86 for embedded development purposes: launching ARM VMs, for example.

How is it "overkill"? Proxmox is so simple to install and administer, I cannot see any use case for manual QEMU/KVM. Who wants to manage machine configs by hand, like a cave person?

And what about redundancy and backups? Even a one-person business needs those, and small businesses arguably have fewer resources to spend on manual DR processes.

You're making a leap. In a small environment virt-manager and friends GUI tools are probably sufficient. Yes, proxmox is obviously nicer, no question, but not really necessary.

As to the "cave person" nonsense: I version control VMs, I can reproduce the whole stack from git, script any conceivable deployment... I'm not a cave person. I've just been inculcated to this whole world of VM management since before proxmox was a thing. It really isn't the hairball you think it is. People routinely author docker compose scripts and collections of k8s yaml deployments that are far more intricate than a VM config, and consider themselves on plane with modern devops.

> And what about redundancy and backups?

What about them? There are many was to solve that, and nearly all of them are better done using storage system tools: NAS, ZFS, NetApp, LVM, EBS, etc. I made that point elsewhere: the real problem with VM management isn't provisioning VMs. It's storage. Solve that and the rest is pretty basic.

Reply on news.ycombinator.com