why shut down VMs when the array shuts down?


Recommended Posts

It would be really good to have an option for this not to happen....

I would like the VM to continue running while the Raid is shut down......

(P.S. the VM is on my cache drive, although I'd be fine with having to move it to a drive

outside the array proper if that would make it work).

Link to comment

I think this option would also be quite helpful, as one of my VMs is what provides the internet to my entire network.

 

I have my VMs installed on an SSD that's mounted outside of the array using SNAP. My docker image/containers are also on this SSD.

 

Would this be possible?

It is the Roadmap area as a feature request.
Link to comment

I think this option would also be quite helpful, as one of my VMs is what provides the internet to my entire network.

 

I have my VMs installed on an SSD that's mounted outside of the array using SNAP. My docker image/containers are also on this SSD.

 

Would this be possible?

It is the Roadmap area as a feature request.

 

Smashing, thanks. i really ought to spend more time browsing the forum.

 

That being said i need to update my signature too, I got a proliant server about 2 months ago!

Link to comment

I have suggested that it would be useful for the cache drive / pool to be continuously mounted and shared, similar to the flash device, with special processes to unmount it. This would pave the way to enable VMs and Dockers running from cache to be able to stay running across normal array stops.

Link to comment

What do you think of this idea?  I admit it may be too confusing ...

 

Add an Apps drive, like the Cache drive, except it mounts at boot and unmounts at shutdown, does not start and stop with the array, and can optionally be a folder on the Cache drive.

 

So you could have -

* Just a Cache drive - everything exactly the way it is now, Cache drive starts and stops with the array; when mounted, provides /mnt/cache

* Just an Apps drive - starts at boot and stops at power down; would need a way to manually mount and unmount for maintenance; when mounted, provides /mnt/apps

* Cache drive and Apps drive - when each is mounted, provides /mnt/apps always and /mnt/cache when array is up

* Cache drive with apps folder - mounted at boot, unmounted at power down, all Cache folders mount and unmount with array; provides /mnt/apps always and /mnt/cache when array is up; the big change is that Cache drive is always mounted, but no /mnt/cache when array is stopped

 

A variant would be Cache folder on Apps drive, but might be problematic.  But perhaps the apps folder on Cache drive is more problematic ...

Link to comment

Add an Apps drive, like the Cache drive, except it mounts at boot and unmounts at shutdown, does not start and stop with the array, and can optionally be a folder on the Cache drive.

 

And/or being able to select disks that are not part of the array to stay up. I have a couple of disks in my server that only store VM images and one also stores my docker.img that are not included in my array.

Link to comment

Good point on where it's stored - I tend to think of the cache drive as not really part of the array, but it's still a mount point.

I'd be ok with having the VM on a drive outside the array if that would keep it from shutting down......

I think there is more than involved than might meet the eye.  For instance at the moment the libvirt daemon is closed down when the array stops and I suspect it might be required by running VM's (I am not sure).  Not sure if anything else that is started when the array is started is also required by VMs.  I already have my VM's on an external drives that I mount/umount via the go/stop files so would be happy to add commands to start/stop VMs there as well if that was all that was involved.

Link to comment

What do you think of this idea?  I admit it may be too confusing ...

 

Add an Apps drive, like the Cache drive, except it mounts at boot and unmounts at shutdown, does not start and stop with the array, and can optionally be a folder on the Cache drive.

 

So you could have -

* Just a Cache drive - everything exactly the way it is now, Cache drive starts and stops with the array; when mounted, provides /mnt/cache

* Just an Apps drive - starts at boot and stops at power down; would need a way to manually mount and unmount for maintenance; when mounted, provides /mnt/apps

* Cache drive and Apps drive - when each is mounted, provides /mnt/apps always and /mnt/cache when array is up

* Cache drive with apps folder - mounted at boot, unmounted at power down, all Cache folders mount and unmount with array; provides /mnt/apps always and /mnt/cache when array is up; the big change is that Cache drive is always mounted, but no /mnt/cache when array is stopped

 

A variant would be Cache folder on Apps drive, but might be problematic.  But perhaps the apps folder on Cache drive is more problematic ...

 

I think it is simpler than this. Right now we have 2 options for array autostart. No autostart and autostart. We can move to three states - autostart, cache autostart, full autostart. Also, when stopping array, you have two options, stop array and stop array+ cache. If cache is mounted you could stop cache or start array. You get the idea. All of the Docker and VM functionality would be available when cache is mounted. Maybe a configuration for a separate apps drive also available. Might want autostart and plain start options on Dockers and VMs so some Dockers will only be startable when array is up and come down when array comes down, while others can be up so long as cache is mounted or app drive configured.

 

As I think about it, you'd likely want cache only shares available when cache drive is mounted.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.