Oof. No.

Wouldn’t do it for a litany of reasons, but the main being that it’s not meant for such things. You want it to be as close to the OS and drivers as possible. Anything getting between Unraid managing the disks is overly complex, and asking for trouble. What happens if the container dies? What happens if the container gets OOMkill’d?

If you’re not going to use it to manage your disks, then I guess no issues, but there’s better suited software for such things.

Yeah, UnRaid does all of that, but from my very basic testing of ProxMox in an old computer, the VM management is much better than in UnRaid. The same goes for VLAN awareness with just 1 nic.

I’m in no way unsatisfied with UnRaid, but I watched a video by Christian Lempa doing something similar, only with TrueNAS instead of UnRaid, which is what got my brain thinking about all these potential options.

www.youtube.com/watch?v=M3pKprTdNqQ

There’s the question of “CAN I do this?” vs “SHOULD I do this?”. I don’t think abstracting your main storage handling software away from where it definitely needs to be is going to net you anything positive, but add more issues and complications.

I’m sure you can find videos of people running drivers out of containers just because it’s possible. Should you though? Nope.

I do have the advantage of having a mirror of my server 2.5K miles away in my brother’s house. That’s probably why I’m thinking about being so candidly careless.

I appreciate the great advise. But now I’m willing to take one for the team and come back with either am horror story or an epic win.

BRB.

Have you considered the increase in disk io and that hypervisor prefer to be in control of all hardware? Including disks…

If you are set on proxmox consider that it can directly share your data itself. This could be made easy with cockpit and the zfs plugin. The plugin helps if you have existing pools. Both can be installed directly on proxmox and present a separate web UI with different options for system management.

The safe things here to use are the filesharing and pool management operations. Basically use the proxmox webui for everything it permits first.

Either way have fun.

I actually never considered this. And if I’m understanding you correctly, this would render using UnRaid unnecessary.

This is great info. I’m going to fit my current ProxMox test rig with a few disks I have (old small disks I have replaced over the years that still work) and test this option first. This might make this easier.

If this works out, I can still keep the server I set up off-site to mirror my storage, right? Even if that is still UnRaid? I need more coffee.

Yup you can. In fact you likely should and will probably find yourself improving disk io dramatically compared to your original thoughts doing this. It’s better in my opinion to let the hypervisor manage disks operations. That means in my opinion it should also share files with smb and NFS especially if you are already considering nas type operations.

Since proxmox supports zfs out of the box along with btrfs and even XFS you have a myriad of options. You combine that with cockpit and you have a nice management interface.

I went the zfs route because I’m familiar with it and I appreciate it’s native sharing options built into the filesystem. It’s cool to have the option to create a new dataset off the pool and directly pass it into a new lxc container.

I’m very inclined to use this method instead.

I would like to ask for some suggestions on the initial process to migrate the data from UnRaid.

Considering that:

• My disk pool is made out of 2 10TB disks, for a total of 20TB
• It also has a 10TB parity disk
• The pool is using just -6TB of the storage

The option I see is:

• Get another 10TB disk
• I can clear the parity drive and copy my data from the pool to that disk for migrating
• Configure the pool disks to RaidZ and once I complete that, use the other 2 disks as parity pool

Or, I bite the bullet, get brand new 10TB disks, 12 to make it Raidz2 and have a storage pool of 40TB (35 usable?). I’m thinking 4 groups of 3 disks each should do the trick. Then use the same method to migrate my data.

With 64GB of ECC RAM, I should have a pretty swift storage IOPS that way.