Hi all,

 

So, I'm trying unRAID again, this time with a view to migrating my media server and Drobo Pro data to it, and re-purposing the Windows Server host that currently serves it up (and runs Plex and the associated services).

Previously I was investigating replacing my desktop with an unRAID build. I have since done that the traditional way (i.e. a new machine), so this has been built out of my old hexacore desktop.

 

Had a little search around, but can't find much on this really, other than it seems that nobody is worried about it.

So I'll ask the question.

 

What happens when the scheduler kicks in to copy a VM disk image from the cache drive to the array, and the VM is active, potentially writing data to the disk?

I think I'm correct in saying that the disk image is seen as one huge file.

 

Does it "just work", in that it knows the data has changed and it's copied again?

Couldn't this infinite loop?

If it doesn't spot the change then couldn't you end up with a corrupt disk image?

Am I missing something here?

 

Perhaps there is a way of not using a disk image, but using the filesystem in its own right?

 

The VM in question is an always on Windows Server DC.

I could perhaps stomach it coming down just before the schedule, and coming back up afterwards, but I'm guessing there's no magic way of doing this?

 

Appreciate any guidance here.

 

Cheers,

Sudo

10 minutes ago, SudoPacman said:

What happens when the scheduler kicks in to copy a VM disk image from the cache drive to the array, and the VM is active, potentially writing data to the disk?

If you mean the mover, it won't move any open files.

Hi, thanks for replying.

 

Yes, I mean the mover.

Doesn't that mean that a running VM will never be written to the array?

 

Oh dear!

A running VM (or any other file) will never be moved to the array, you can have a VM on the array or have it on cache and backup to the array, there are scripts for that.

You better don't have a VM running from an array disk if you have an SSD you can use. The performance is really bad of an array drive. Think of an old slow laptop with an traditional HDD vs the same laptop with an upgraded SSD. Having the VM always sitting on the cache and a scheduled backup plan is the better choice. An good example for an script you can find here:

 

 

@bastl

Yeah, I am planning on adding an SSD, but sounds like you are suggesting doing so without using it as cache, but using it as an "unassigned device"?

That's fine, but I guess I may want both ultimately.

 

That script does look useful.

Am I correct in saying it will stop the VM, back it up, then start it back up again?

 

I'll have a look later, to see how much control it gives me.

 

Cheers

You can have the vdisk wherever you want. Depends on the size and how much VMs are accessing the same device at the same time. pasthrough vs. UD vs. cache. It_s your choice 😉

 

6 minutes ago, SudoPacman said:

Am I correct in saying it will stop the VM, back it up, then start it back up again?

That's exactly what the script does. Specify which VMs you wanna backup. Exclude vdisks if you want, start the VM or not, compression, how many backups to keep, there are a couple things you can setup.

 

 

Just as a quick update, in case anyone comes searching for similar.

 

I put in a couple of SSDs, one for a cache and another for vdisks, and set up the suggested script.

Works brilliantly, and as a nice bonus the VM runs a lot better too.

 

Thanks for the help all.