Keep certain VM's running without array started

[JonathanM]

52 minutes ago, johner said:

Array = parity array…

 

docker and VMs should be able to continue to run on a cache etc.

 

basically make each array independent with their own start/stop/check buttons etc.

 

this might then also support multiple parity arrays…

How do you handle user shares that have part of their storage go away when that pool is down? For instance, I keep some VM vdisks on the parity array, and some in a pool. They all seamlessly are accessible via /mnt/user/domains, and I move them as needed for speed or space, and they all just work no matter which disk actually holds the file.

[JustOverride]

12 minutes ago, JonathanM said:

How do you handle user shares that have part of their storage go away when that pool is down? For instance, I keep some VM vdisks on the parity array, and some in a pool. They all seamlessly are accessible via /mnt/user/domains, and I move them as needed for speed or space, and they all just work no matter which disk actually holds the file.

In THAT case, whatever uses the array would go offline and not work obviously for your particular scenario. But what WE'RE asking is for the VM's/dockers that remain in a stand alone or cache drive. There could also be a way to mark a VM/docker as 'keep in cache/alive' or w.e so that it is not moved to the array. Plenty of ways to implement it really.

(Edit) You know when you really look at it, what we want is to be able to keep our internet going while doing w.e that requires the array to go down. Pfsense, ubiquity, homassistant? etc. That's what we're really asking here. These things run mainly in RAM too so I'm not seen what the big problem is.

Edited November 2, 2022 by JustOverride

[johner]

25 minutes ago, JonathanM said:

How do you handle user shares that have part of their storage go away when that pool is down? For instance, I keep some VM vdisks on the parity array, and some in a pool. They all seamlessly are accessible via /mnt/user/domains, and I move them as needed for speed or space, and they all just work no matter which disk actually holds the file.

That’s a design and user experience question.

 

obviously those specific VMs will not be able to be running if ‘their’ storage is offline.

 

what experience do ‘you’ want? With this requirement enabled, it could be: prevent any vm/docker from using the parity array? (Maybe an easy MVP release), or more complex where the stop solution goes and traces back users of its array and stops any specific (singular VMs, specific shares etc.) services first - I suggest this as a later/subsequent release if people want this experience.

 

first things first, agree the requirements, accept the requirements, scope a release, then design it.

[ReLe]

Quite interesting thread. Came here trough Google when searching what to do in my situation. I thought that it would be possible somehow do this or at least maybe it would be implemented.

 

I have to migrate my unraid to mATX case when we move for 2 months to escape apartment water pipes renovation. I can't take the array disks with me (power consumption and there is no room for large tower) but I need to run the vm's. 

 

Currently thinking of moving mobo (small B660 with 12100) and only vm ssd + os ssd to small case and install proxmox to run the vm's. After I move back I probably will run Unraid as vm in proxmox with nic&hba passthrough, going forward to get around the vm debacle.

 

I have had my fights with array before, having to run repairs etc to disks and I can't have the downtime for the vm's during those periods.

[Jarsky]

I'm interested in this feature as well. 

 

My VM's & Dockers run on their own pool (NVMe mirror) so have nothing to do with the main array. Some of them may access an SMB/NFS share as a mount, but in the case where the array is down that mount will just go unreachable in the VM. 

 

Theres times I do storage maintenance like the last 2 weeks, where there shouldn't be a need for me to stop every Docker & VM to just replace/upgrade a drive in the primary array. 

 

I get this might be complicated though when users have VM's that have vdisks on /mnt/user

[Joseph]

+1 from me as well! Hopefully we'll see this in a future release sooner, rather than later.

[Nokedr]

+1

[fwiler]

Just want to add my support for this request.

[NathanR]

+1

I am constantly modifying my Unraid setup as I learn new things.
 

I rarely need to turn off my HA VM or my Win 10 VM; yet taking down the array does that.

 

Worse - turning on the array doesn't auto-on the VMs only Dockers

 

---

 

I read numerous times about how to implement this when skimming through this thread.

I also see questions about licensing, what to do when a mapped share is down, how to handle different locations for dockers/vms, etc.

 

The devs really would be the experts at how as there are numerous obstacles to overcome.

Array parity behavior, Array licensing behavior, Access to drives if array is down, Etc.

I get it, there's lots to think through.

 

---

 

Here's my take.
Requirements - a working cache pool

This forces users to not use the array. Limits to more experienced users.

 

Licensing - Pro version enables support for multiple offline pools.

Solves all licensing issues. All the licensing talk is too complicated. Why make code changes when you can make policy changes that make sense.

 

Warning - Any mapped shares that a docker/VM uses will not work and can crash your docker/VM if the internal software cannot handle it.

Why make this a Limetech issue? Push the responsibility on the user & container developer.

 

Ex. 1) Plex - libraries shared to spinning rust on array - okay who cares. Plex handles missing library locations gracefully.

Ex. 2) Windows VM  - can't find a share. Windows will handle that gracefully (or not) lol.

Ex. 3) HA, FW, UtKuma, Unifi, etc. - These reside entirely inside their docker/VM container. They only write out or read out if they have mapped syslog folder or something. Too complicated to check if it's on an array, etc. Who cares. Responsibility is on the user.

 

New Buttons & GUI changes

Array-Start/Stop button (1) - main array

Array-Start/Stop button (2) - cache pool 1

Array-Start/Stop button (n) - cache pool n [drop down menu button]

 

 

---

 

Implementation 0.1
'All or nothing.'

Shares cannot point to the 'DockVM' pool [they can, but if they do, then you can't keep DockVM pool online]

All Online Dockers volume mappings point to DockVM pool

All Online VM disk mappings point to DockVM pool [This simplifies the programming required. sure there are dedicated disks, usb disks etc. who cares. Start simple]

 

Offline Dockers/VMs are not considered [if they're offline and your turning off the array but not the DockVM pool...who cares]

 

(3 pools) [You could forgo the cache pool of course, but most pro users are going to have a setup like this]

Array [unraid] [hdd]

Cache [whatever; raid, probably 1 or 0+1] [probably ssd or nvme]

DockVM [whatever; raid, probably 1 or 0+1] [probably ssd or nvme]

 

Clicking stop on the array - "error docker.list & VM.list are online & uses array volume mappings"

I would use this right now. I'd make my current cache drive only for docker & vm until implementation 1.0 can roll out.

I don't need to copy files to my cache and then use the mover to move to spinning rust.

I'd rather have my dockers & vms stay up right now.

Plex docker running? - I'd have to shut it down. Who cares, if the array is offline no one is watching movies anyways.

But my HA & W10VM (with internal database on vdisk) stay up; woot.---

 

---

 

Implementation 1.0
'Almost All or nothing.'

 

All Online Dockers volume mappings point to cache

All Online VM disk mappings do not point to array

 

All Offline Dockers cannot start without both array & cache 'online'

All Offline VMs cannot start without both array & cache 'online'

 

The only reason this is separate from 0.1 is due to the fact that the shares are mapped to the same cache pool as the dockers & VMs. Thus I'm assuming there will be some code changes & checks to ensure compatibility.

 

Plex docker - must be shutdown to shutdown array [but keep cache online]

 

---

 

Implementation 2.0

'Granular approach'

 

All of the above but:

 

Checks if the primary storage for docker or VM is on the cache pool.

Ignores mappings to array (but reports warning)

 

Plex docker - stays running; volume mappings to array are offline/not working.

Hopefully container doesn't crash.

 

---

 

Implementation 3.0

'Granular Auto Approach'

 

All of 2.0 plus the ability to auto-on/off dockers & VMs based upon which pool is going up/down.

Global setting for restart Unraid OS auto-start or start/stop array pool(s) to auto-start Docker/VMs.