Has there been a decision on how a VM is treated when the unRAID array is stopped ? Ideally the VMs would continue to stay alive whether the array gets stopped or started.

 

What's the current situation and has there been a decision going forward ?

Current Situation...

 

Assuming you are putting your VMs on the cache drive or unRAID itself... They disappear when the array is stop.

 

I'm sure Tom could provide an option in the WebGUI that a user would check (or not) that when the array shuts down, it doesn't unmount the cache drive.

 

He would no far better than me if this is a wise thing to do or not but that is one way of doing it.

 

 

An option to leave the cache drive mounted sounds like a good idea (and should probably be the default).  This could often be convenient even if not running VM's. It might often avoid the need to run a drive that is outside unRAID control as many users seem to do.  You would also need to allow (probably via your suggested checkbox) for the cache drive to also be unmounted as part of stopping an array so that one can remove/change the cache drive if that is required.

 

Another big issue is the whole idea of providing an agreed way of stopping VM's in the event of one wanting to power off or reboot the system.  It may be that the brute force approach of aborting the VM's is OK, but I am not sure if a tidier solution might be desirable.

An option to leave the cache drive mounted sounds like a good idea (and should probably be the default).  This could often be convenient even if not running VM's. It might often avoid the need to run a drive that is outside unRAID control as many users seem to do.  You would also need to allow (probably via your suggested checkbox) for the cache drive to also be unmounted as part of stopping an array so that one can remove/change the cache drive if that is required.

 

Another big issue is the whole idea of providing an agreed way of stopping VM's in the event of one wanting to power off or reboot the system.  It may be that the brute force approach of aborting the VM's is OK, but I am not sure if a tidier solution might be desirable.

 

The option to keep the cache alive is a good one.  Especially as I imagine most would store the VMs on cache.

 

I have no idea on the shutting down on VMs on machine shutdown, but I would assume that if I issue the command manually (webgui or powerdown script) that i would be asked to shut them down brutally or stop and gracefully pull them down.

 

On the same taken I wouldn't want an automated shutdown event, like a UPS triggered event, to have to wait for an answer before shutting down.

 

I think there needs to be more thought around how unRAID deals with VMs before 6.x goes stable.  At the moment the focus seems to be on the VMs themselves and not unRAID.

I would like to knows toms thoughts on adding a special VM drive which behaves like you describe above and remains mounted at all times, configurable by the web GUI.

 

A hybrid cache / VM datastore drive if you will.

 

Sent from my Nexus 5 using Tapatalk

 

Does XEN have a SaveState command (like VirtualBox) that allows to save a complete state of the VM (including memory) to disk and then restore the VM as if it was never shutdown quite fast.

 

This is the method that I use on my VirtualBox plugin.

 

I would like to knows toms thoughts on adding a special VM drive which behaves like you describe above and remains mounted at all times, configurable by the web GUI.

 

A hybrid cache / VM datastore drive if you will.

 

Sent from my Nexus 5 using Tapatalk

 

An option for some, but not all.  I don't have any spare slots or sata ports on my mobo so I'd prefer a solution that uses my cache drive, that is used for apps and not caching.....

Hybrid for me meant it would do both duties

 

Sent from my Nexus 5 using Tapatalk

 

 

Hybrid for me meant it would do both duties

 

Sent from my Nexus 5 using Tapatalk

 

So what you meant was using the cache as the VM drive as well ? Novel idea.

If I had to guess, keeping the Cache running after array stop might be problematic because the Cache is part of the fused user shares.  As School says, Tom knows much better than us.

 

An idea that comes to mind would be for the WebGUI to allow us to assign the Cache and VM Store to partitions rather than a whole disk.

 

That way the array can be stopped and Tom doesn't have to figure out how to deal with keeping the user shares accessible via NFS/SMB etc. but the drive's other partition, the VM partition, remains mounted and accessible.  It will also allow us to save a SATA port.

 

Obviously the mechanics of making this all happen would not preclude mounting Cache and VM Store on dedicated drives either since you'd just use a full disk partition.

 

Just a thought.

 

PS: the reason I think it might be a problem to deal with keeping the user shares up is because then Tom would have to delineate which shares to keep exporting. 

    Cache only: Export

    Use Cache: Export 

    Not Cached: Do Not Export

I think that might be a risky proposition.  But again, Tom knows best.

I would like to knows toms thoughts on adding a special VM drive which behaves like you describe above and remains mounted at all times, configurable by the web GUI.

 

A hybrid cache / VM datastore drive if you will.

Not sure why it needs to be a separate drive.    Just an enhancement to be able to keep the cache drive mounted while the array is stopped seems to be all that is required.  One would probably want a larger cache drive but that is not really an issue I would have thought.  Might also be a good reason to upgrade the cache drive to a SSD to improve VM performance.

If I had to guess, keeping the Cache running after array stop might be problematic because the Cache is part of the fused user shares.  As School says, Tom knows much better than us.

When the array is stopped the /mnt/user and /mnt/user0 mount points disappear anyway so it does not feel like it would be an error.    However as has been said this all needs thrashing out and is exactly the sort of things for a beta cycle to resolve.

Another big issue is the whole idea of providing an agreed way of stopping VM's in the event of one wanting to power off or reboot the system.  It may be that the brute force approach of aborting the VM's is OK, but I am not sure if a tidier solution might be desirable.

 

I have no idea on the shutting down on VMs on machine shutdown, but I would assume that if I issue the command manually (webgui or powerdown script) that i would be asked to shut them down brutally or stop and gracefully pull them down.

 

Xen is what it is and it shuts down VMs the way it does. Xen will try to do it gracefully but if the Linux Distro / VM doesn't play nicely... There isn't anything Tom / we can do to change that.

 

Businesses that run ESXI, Hyper-V, Xen, XenServer, KVM, etc. all are aware of this and deal with it accordingly. In my experience and what is considered the best approach is to shutdown the VMs within the VMs and after all the VMs are powered off.... you then poweroff / reset the Host. 

 

On the same taken I wouldn't want an automated shutdown event, like a UPS triggered event, to have to wait for an answer before shutting down.

 

This is something we should discuss / educate others on so they can setup their system / UPS / scripts to shutdown in a way that works for them.

 

I think there needs to be more thought around how unRAID deals with VMs before 6.x goes stable.

 

Is it just the things you mentioned... UPS, shutdown, cache drive or is there more?

 

At the moment the focus seems to be on the VMs themselves and not unRAID.

 

What do you mean?

 

Do you want us (the users) to focus on unRAID instead of VMs?

 

Do you want Tom to focus on unRAID instad of VMs?

 

If it's Tom, he is done with Xen aside from some very minor tweaks with config files. From what I gathered, I don't think he is releasing / managing / supporting VMs directly.

 

Ironic, me, others have far more experience / knowledge of Xen than Tom... We will continue to educate / share / tell Tom (and everyone) the changes / tweaks that need to made to make Xen stable in unRAID / Slackware 14.1. Tom is focused on unRAID and looking for our input / ideas / suggestions on how best to implement it.

 

After finally installing / tested Xen in unRAID last night... I submitted my latest suggestions in the beta thread on what Tom needs to change and why.

 

There are only 2 more items I am working on. Once I figure out the best approach / method for those... Xen is done (aside from an optional WebGUI or Plugin that would be helpful).

If I had to guess, keeping the Cache running after array stop might be problematic because the Cache is part of the fused user shares.  As School says, Tom knows much better than us.

When the array is stopped the /mnt/user and /mnt/user0 mount points disappear anyway so it does not feel like it would be an error.    However as has been said this all needs thrashing out and is exactly the sort of things for a beta cycle to resolve.

 

Hmmm yes I suppose that would just leave /mnt/cache accessible.

 

I take it back, that should probably work just fine

If I had to guess, keeping the Cache running after array stop might be problematic because the Cache is part of the fused user shares.  As School says, Tom knows much better than us.

When the array is stopped the /mnt/user and /mnt/user0 mount points disappear anyway so it does not feel like it would be an error.    However as has been said this all needs thrashing out and is exactly the sort of things for a beta cycle to resolve.

 

Hmmm yes I suppose that would just leave /mnt/cache accessible.

 

I take it back, that should probably work just fine

 

Actually, I've never thought to see if the cached drive apps are still accessible and running after stopping he array today.  Maybe there is no issue.

 

But this discussion would also have impact on the idea to have a common NSF mounted /home or /root outside of the VM

aaaannnd yup when the array stops /mnt/cache goes away.  Everything goes away.  The only thing I have left in /mnt is my GO script mounted appdisk

As mentioned previously, many of us looking at using the VM for plugins (SAB, SB, Plex) are going to need to rely on /net/Tower mount points for the VM to work anyways due to space issues. I think it makes sense for the VMs to shutdown when you are stopping the array (just like the plugins don't work in 5.0 when the array is turned off).

 

The more we leverage these VMs the more dependencies we are likely going to have on the overall storage system, so having a clean shutdown process that includes VMs is a good idea. In the meantime I agree with SchoolBusDrivers suggestion of manually powering down VMs cleanly prior to stopping the array for shutdown/reboot.

 

Would we not potentially run into an issue shutting down the array if the VMs are active? I would guess we'd need to break dependencies for the array shutdown for it to work now (unless the cache drive isn't a dependency).

 

I know I was looking to reboot yesterday and forgot I had a pre-clear running in the background. The GUI just kept reporting it was trying to unmounts drives and the server wasn't available via Putty at that point. I needed to walk over to the server and log into the console to do anything more on the server. I would guess that active VMs are going to cause similar situations in the current state.

 

 

As with all things, if possible it would be nice to have an option.  That is, maybe a check box to determine if VM's should be shut down with array stoppage, or not.  I can see some cases where it would be nice to not have to take down my VM just because I want to stop the array.  And i can imagine setups where VMs would tolerate that.  Such as a VM hosted on a non-array drive, or a "VM partition" on the cache drive that survives array-stop and samba as the pathway from the VM into the array shares.  With something like that i see no reason to need to stop a VM just because the array is stopping.

 

That said, I'm a noob and I'm open to being told there are best practices I'm just not aware of.