It’s not exactly a single tool, but torsocks kind of enables doing what you’re describing. The syntax would be something like torsocks curl $url

1. This sounds like a weird one. It would be helpful to have some more info about your network. Would you share your PVE host’s /etc/network/interfaces file and the config file for the VMs (from /etc/pve/qemu-server)?
2. Excellent
3. I think ZFS would likely help since it can make use of block level snapshots. I think the way to move things over would be to create a ZFS datastore in Proxmox and then just migrate each VM’s disk.
4. Personally I think this is a bit simpler in an LXC container and there are a bunch of tutorials to help. These two are similar to my own setup:

• https://blog.bekh.fr/jellyfin-lxc-with-hardware-transcoding-igpu-passtrough/
• https://www.wundertech.net/installing-jellyfin-on-proxmox/

Hope some of that helps

Not sure if this is the kind of thing you’re after, but I think learning a little about the very fundamental pieces of these systems really helps to understand the mechanisms at work.

One place that was really useful to me was years ago, the Security Now podcast did a series called “How the Internet Works” ( I think). Steve Gibson went over all the principles layer by layer and it helped my understanding a ton. This was many years ago, so the rest of each episode is probably filled with really old security news, but the main bits are as relevant as ever.

Unbound can query the root dns servers, but it’s also commonly used as a recursive resolver, which just uses a server upstream, similar to systemd-resolved. I use unbound network-wide, but I have it querying 9.9.9.9 to take advantage of their filtering.

You may already have a local dns caching mechanism on your computer. I think by default Ubuntu uses systemd-resolved (it does on my desktops anyway). If you check dig it’ll show lookups coming from 127.0.0.53. With that in place, your local machine is caching lookup results and anything it doesn’t know, it’s forwarding to the network’s resolver (which it gets via dhcp, usually).

I’ve only ever tinkered with it slightly on a Proxmox host, but I ran it locally when I was testing it and it was glad to setup the VMs on the same system it was on.

You can definitely run VMs or containers on your desktop system and there are a lot of ways to do that (as others have said). If it’s the automated, reproducible setup you’re after (and you are purposely avoiding docker), give a look to terraform and ansible to create and provision your software.

I set up an old thin client with Debian and lxqt to connect to a VM on Proxmox. Got the idea from an Apalrd’s Adventures video about VDI. It worked pretty well on a decent network, but it really suffered on high latency networks.

That’s a bummer of a price difference for electricity. I think using the R320 for storage and adding some Lenovo sff units makes a lot of sense. I have one of the Lenovos in my hodgepodge virtualization cluster and it has been rock solid (as has my R320 in providing storage).

Keep an eye on lowendbox.com’s hosting offers. There’s some junk to wade through, but it sounds like exactly what you’re after.

It sure will handle a remote VPS, it’s just not as automatic to set up as it is with PVE.

I put this off for a long time, but I finally did it this weekend.

Basically, you install the proxmox-backup-client utility and then run it via cron or a systemd timerto do the backup however often you want.

You’re responsible for getting the VPS to communicate with your backup server (like pretty much any self-hosted service), so some sort of VPN between them would be good. I used NetBird for that part and I have a policy that allows access from the client to PBS only on TCP port 8007.

I’ve been quite happy with Proxmox Backup Server. I’ve had it running for years and it’s been pretty solid for all my VMs/containers. There’s also a bare metal client, which I’m adding to a couple cloud VPS machines this weekend. We’ll see how that goes.

Also, since it’s just Debian under the hood, I also use the PBS host as a replication target for my ZFS datasets via sanoid/syncoid.

I just had to do this. Don’t skip the release notes. They’re really good at highlighting potential pitfalls, just scroll back through and look for the heading “Breaking Changes.”

In my case there were a few, but they were only for API calls I’m not using, so I just did the update in one go and it worked out great. (Of course, I made sure to take a backup first.)

Oh! Also, try posting this here: https://practicalzfs.com/. That’s a discourse forum really focused on ZFS. Jim Salter runs it and Alan Jude often contributes advice. There are some folks there who know ZFS inside and out.

Checksum errors can often mean a failing component. It could be the other drive or maybe a sata cable. Is the original pool mounting correctly? If so, you should be able to do a simple rsync to move it to the new pool.

Take this with a grain of salt, the more I re-read, the more I realize I’m making assumptions about your setup that may or may not be true. First, I’m making an assumption that you’re doing ACLs for samba shares (and I know that system better on FreeBSD than Linux). I’m also assuming based on your description you want everyone to have access, but not write access.

I think you could do an officewide group with read-only permissions on all of the shares and then set the unix group to the department.

So, for your HR team you’d do chgrp -R hr /path/to/parent/shares/hr and setfacl -m d:g:rwx /path/to/parent/shares/hr and add the officewide group’s read-only perms: setfacl -m d:g:officewide:rx /path/to/parent/shares/hr. Rinse and repeat for each share.

Not sure if this is what you’re after, but maybe it’ll help lead in a good direction.

Not sure how wide a variety of sizes there are, but I’d search for “threaded inserts.” You drill the holes and screw the inserts in and that gives you an interface for machine bolts. I’ve only seen them in bigger sizes, but I wouldn’t be surprised if there are some that would fit standoffs.

You could likely use dd or clonezilla to create a duplicate of your boot drive and boot your laptop right from that, but that’s not quite what you’re after.

There are some distros lately that use a declarative config file to set the whole thing up that I think is much more what you have in mind. The big ones that come up a lot are nixOS and Fedora Silverblue. Maybe one of those systems would be to your liking.

That’s awesome, I’ll definitely be interested to see how it all works out.

Yeah, I started working on it once a couple years ago and getting it spun up was a chore. Life got busy and I never finished.

That imapbox looks pretty interesting. Thanks for tracking that one down.