Docker containers and VMs on dedicated unassigned disk - what to do with default shares?

[hamzas]

Hi all,

 

I would like to run all Docker containers and VMs from a dedicated SSD, managed through unassigned devices. Device in question is formatted XFS and auto-mounted at boot:

 

 

 

I've also modified the Docker and VM settings and pointed required locations to this dedicated SSD:

 

 

 

I created those folders manually and configuration is saved without any errors.

 

Where this gets confusing is that there are the default shares: appdata, domains, isos and system. What to do with these, given that I am pointing these to folders created in the dedicated SSD, should I just delete these shares?

 

With the shares present, when I start the array these folders get created in the cache pool and the paths specified (pointing to the dedicated SSD) are seemingly ignored.

 

Are there are any other config files I should be editing?

 

Thanks.

 

 

Edited January 8, 2021 by hamzas

[Jessie]

2 hours ago, hamzas said:

Hi all,

 

I would like to run all Docker containers and VMs from a dedicated SSD, managed through unassigned devices. Device in question is formatted XFS and auto-mounted at boot:

 

 

 

I've also modified the Docker and VM settings and pointed required locations to this dedicated SSD:

 

 

 

I created those folders manually and configuration is saved without any errors.

 

Where this gets confusing is that there are the default shares: appdata, domains, isos and system. What to do with these, given that I am pointing these to folders created in the dedicated SSD, should I just delete these shares?

 

With the shares present, when I start the array these folders get created in the cache pool and the paths specified (pointing to the dedicated SSD) are seemingly ignored.

 

Are there are any other config files I should be editing?

 

Thanks.

 

 

As an alternative, have you considered going to v6.9 and running multiple caches?  Then you can run your system as a standard setup including the shares. ie run the appdata/vm's on one cache and everything else on another cache. Then all of your data is protected.

 

[JonathanM]

33 minutes ago, Jessie said:

Then you can run your system as a standard setup including the shares. ie run the appdata/vm's on one cache and everything else on another cache. Then all of your data is protected.

Cache pools can be single devices, which don't have redundancy, and it's possible to set up BTRFS RAID volumes unassigned. Drive redundancy isn't a factor, but the ability to manage multiple pools in the share system certainly is an advantage.

[Jessie]

19 minutes ago, jonathanm said:

Cache pools can be single devices, which don't have redundancy, and it's possible to set up BTRFS RAID volumes unassigned. Drive redundancy isn't a factor, but the ability to manage multiple pools in the share system certainly is an advantage.

Yeah, you can run everything as a single device, but the whole point of unraid is redundancy.  At least it is for me.  In Australia the cost of running 2 500gb ssd protected arrays is the same as running a single protected 1tb array.  So if you were originally planning a single array on v6.83, halve the size of each ssd and buy twice as many and go to 6.9 for 2 arrays. My thinking is if you are going to use unraid, so you can break out into unprotected single arrays again, you might as well just build the system on a vanilla windows platform.

 

Edited January 9, 2021 by Jessie

[hamzas]

9 hours ago, Jessie said:

As an alternative, have you considered going to v6.9 and running multiple caches?  Then you can run your system as a standard setup including the shares. ie run the appdata/vm's on one cache and everything else on another cache. Then all of your data is protected.

 

I am on 6.9-rc2, have not really thought of this (my first unraid setup) so thanks for the pointer!

 

My Docker and VMs are mainly for development/testing so don't really need redundancy but I created the "Apps" pool with btrfs in case I change my mind later on.

 

 

[hamzas]

Still not right...

 

Docker and VM settings:

 

 

 

Relevant shares are set up to use only the Apps pool:

 

 

And the Apps and Cache pools:

 

 

Apps pool device is empty?

[Jessie]

25 minutes ago, hamzas said:

Still not right...

 

Docker and VM settings:

 

 

 

Relevant shares are set up to use only the Apps pool:

 

 

And the Apps and Cache pools:

 

 

Apps pool device is empty?

Do you have an array?  (Mechanical hard drive) I assume you do.

Try setting appdata, domains and system to disk 1

Then set cache to preferred.  This will move them to the cache if there is enough room.

Then try a move.

You will probably find they stay on the array because they are active.

so go to settings and turn docker engine off and move again.

The directories should move to the cache.

Then go back and turn docker on again.

(I just added to this)  Start again here

Looking at your shares above, on a normal unraid setup, you would have media and software shares on the mechanical array. ie your big hard drives. Speed is not critical for these files.  I usually put isos in the array as well because those files are normally used once to install a vm etc.

So to unscramble the egg, with no duplication, set up unraid so you have a disk1 mechanical drive formatted as xfs.

Leave your 2 ssd devices as is.  I assume your dockers and vm's are on the samsung.

Set all cache settings to yes.

Now do a move.

This should move all files to the array (mechanical disk 1)

if it doesn't, go to settings and disable dockers and vms.

Do the move again.

Once all the shares are on the mechanical, change share preferences for appdata, domains and system to "Preferred Apps"

Do a move again

That should move those shares to the apps cache drive.

At this point I'd reformat the samsung drive to btrfs. (or if you are only experimenting, dont bother.)

You can do this by stopping the array and changing the xfs to btrfs then restart the array.

finally go back to settings and turn docker and vms back on.

your appdata should then be working on the ssd's and you slow large data will remain on the array.

When you add data to the media and software directories, it will save to the ssd's because cache is turned on. Then at 3am the mover will run and put it on the array.  Alternatively, you can click the move button and do it immediately.

 

 

Edited January 9, 2021 by Jessie