I have a trusty UnRaid server that has been running great for almost 3 years now, with some kinks and headaches here and there, but mostly very stable. Now I’m entertaining the idea of setting that box up with ProxMox, and running UnRaid virtualized. The reason being that I want to use UnRaid exclusively as a NAS and then run all dockers and VMs on ProxMox (at least that’s how I’m picturing it). I would like to know your opinion on this idea. All I have is Nextcloud, Immich, Vaultwarden, Jellyfin, Calibre, Kavita and a Windows VM I use to update some hardware every now and then. I mainly want to do that for the backup capabilities in ProxMox for each instance. Storage is not a concern, and I have 64GB of ECC Ram running in that box. What are the Pros and Cons, or is it even worth it to move all this to ProxMox?
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.
That sounds like a great idea.
At the moment I am using Openmediavault as a VM within proxmox - I pass my HDDs through to this VM. Openmediavault let’s me do all the stuff I want to: Share folders via SSH, NFS and raid-management.
Do you know if I can do the same with proxmox directly? Do you maybe have a link where this way is described in detail?
At its core cockpit is like a modern day webmin that allows full system management. So yes it can help with creating raid devices and even lvms. It can help with mount points and encryption as well.
I do know it can help share whatever with smb and NFS. Just have a look at the plugins.
As for proxmox it’s just using Debian underneath. That Debian already happens to be optimized for virtualization and has native zfs support baked in.
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.
