Cache Pool Size Question

[jdubbs23]

I am about to add a cache drive(s) to my setup and I have a question about how this will work with VMs and the other folders that will prefer the cache drive (appdata, system). I have a virtual disk image for my sole VM that is 500GB, does that mean that I have to have at least a 500GB cache pool available (and likely more to handle the size of the other folders that will be stored on the cache)? If so, is there a way to reduce the vdisk size without messing up the VM?

[JonathanM]

1 hour ago, jdubbs23 said:

does that mean that I have to have at least a 500GB cache pool available (and likely more to handle the size of the other folders that will be stored on the cache)?

Yes, assuming you want that specific vdisk image to live on the cache pool. You can leave it where it is, you just wouldn't benefit from the speed.

1 hour ago, jdubbs23 said:

If so, is there a way to reduce the vdisk size without messing up the VM?

That's a tough question. In a nutshell, if the actual data allocation inside the vdisk file can be forced to move to a smaller space, than yes, it's possible. However... the mechanics of doing that vary by the VM OS, and how that's handled. If you can shrink the partition inside the vdisk using tools in the VM OS, than it's relatively straight forward to copy that partition to a new smaller vdisk file. I wouldn't actually attempt to move the vdisk image, I'd back up and restore the OS to the new vdisk, clone the xml to a new VM, and change the vdisk pointer in the xml to the new location. That way if something messes up you can keep using the old VM while you try a new approach.

 

Depending on your technical skill level, it might be less frustrating to just keep the old VM where it is, and set up a new one using the old as reference to how you would do things differently in the future. 😀

 

However, as long as you keep a copy of the original vdisk image intact, there's no harm in playing.

[testdasi]

Vdisk files are thin-provisioned as far as I can tell so they will only occupy the space that they actually need.

I know for sure this applies to qcow2 vdisk type.

I think it also applies to raw as well but haven't used raw for quite some time so things might have changed.

 

So you can theoretically have the cache pool being smaller than the vdisk but that is probably not recommended.

If you run out of free space due to the vdisk expanding then your VM will go into pause mode (and like irreversibly so until you free up more free space).

[JonathanM]

5 minutes ago, testdasi said:

Vdisk files are thin-provisioned as far as I can tell so they will only occupy the space that they actually need.

I know for sure this applies to qcow2 vdisk type.

I think it also applies to raw as well but haven't used raw for quite some time so things might have changed.

 

So you can theoretically have the cache pool being smaller than the vdisk but that is probably not recommended.

If you run out of free space due to the vdisk expanding then your VM will go into pause mode (and like irreversibly so until you free up more free space).

Yes, as long as you copy preserving the "sparseness", it's likely that the OP wouldn't need to do anything. Until everything crashes from low space. Both qcow2 and raw are thin provisioned by default.

 

The worst part about sparse files for VM's is the difficulty in recovering space on the host drive, even when you delete files in the VM, they still take up space in the vdisk until you force things, using a utility to zero out free space, and possibly defragmenting.

 

Better to deal with the issue head on now, when it's easier and you are working from a known quantity instead of trying to recover from a crash.

 

As a rule of thumb you should never overprovision a single vdisk to more than the total space available to the volume. Now, multiple vdisks? Sure. I probably have 1TB provisioned on a 480GB cache drive, but that's spread over 10+ VM's, most of which are experimental and subject to being blown away whenever needed. As long as you keep an eye on free space and keep at least 10% open, I've never run into an issue.

 

Normally I keep my VM's lean and mean, as all the juicy bits stay on the shared array, to be shared to any and all VM's that are in need.

[jdubbs23]

Thanks for the info everyone. So my main issue is that I started up a Debian VM with a big vdisk (500G) because I was planning to run a bitcoin full node, and this will take up lots of space (its currently synced and at 310G). I was planning to use 2x 250GB SSDs for my cache, and so this vdisk won't fit. I'm wondering if there is somewhat that I could run a smaller VM with a smaller vdisk image and move the location where the full node bitcoin blocks are stored onto the array. Does this make sense?

[JonathanM]

You should be able to point the client at a mounted share.