Guidance sought on provisioned space vs used space

[GregRoberts2011]

As per the topic, after guidance on this.

Is provisioned space a concern or just for guidance, does the system use the used space to determine when you physically run out of space ?

How is provisioned space determined ?

I did a search in vmware kbs for "provisioned space versus used space" and got zero.

If the later then thin provisioning would seem to be the go as we keep on running out of space and most VMs are think provisioned.

However i believe it is no easy task to move from thick provisioned to thin.

Thanks!

[HughBorg707]

Greets,

This is off the top of my head so apologies if something isn't 100% accurate...

As I understand it and have implemented, provisioned space is how you fool the operating system into believing that it has more space than is actually available. VMware doesn't step in and say how much you're allowed to fool the system, you have to monitor yourself.

For instance, on my test network I have an iSCSI unit with 1TB of mirrored space. At the moment I have about 70 different test VM's that only run time to time when needed, so their hard drive consumpton doesn't really grow much if at all.

The thing is that vCenter tells me that I have provisioned about 3TB+ of space total, meaning each one of my VMs, if they were to demand their alotted space all at once (much like a run on the bank) my storage would run out. There have been articles written about this very subject, especially when someone else in your organization creates a snap shot that "SAPS" any remaining hard drive space you had available.

In a production network this could be dangerous if not monitored . In a test network it enables you do do so much more with less. But much like writing a naked put option in the stock market (you're able to sell something you don't even own) it can be very useful. Treat it like a loaded gun, however, with respect.

As for thick to thin provisioning, you just need to migrate the VM from one datastore to another and choose the thin provisioned option. Once its completed and is thin, you can migrate it back. This works well to reclaim some of your actual used drive space.

Regards

Hugh

http://www.1zero1.net

[GregRoberts2011]

Hugh

Thanks for this. I haven't had much sucess going from thick to thin or vice versa and i suspect it is to do with snapshots.

(size option is greyed out)

What is the best way to remove these if i am on the money ?

Thanks

[HughBorg707]

Yes, as I recall you can't do a thick to thin provisioning change with snapshots. You'll find that there will be features that won't allow you to do something because of an attached snapshot.

One way to consolidate the snap shot files if your VM can stand some downtime is to shut it down and then clone it. Cloning will collapse the delta's. You can then fire up the fresh clone and be on your way.

If you can't power the VM down and you only have 1 snapshot, I know that you can simply delete it. Your VM will consolidate the delta file and your recovery point will disappear and the VM will run as it is now. If you have multiple snaps though there are some issues involved that you might want to read up on.

Funny, snapshots are also a loaded gun I got myself into trouble with. I had my blog crash because of an update a while back. I didn't do a snapshot before the update ( I do now for sure) and I had to learn some in depth linux real quick to get it back and running.

Long story short I ended up with 7 snapshots representing each time I successfully fixed a part of the problem. Later when I wanted to consolidate, I powered off and cloned it. This was before I knew more about VMware than I do now, but in the end it worked perfectly.

I've read some horror stories about problems deleting snapshots so really explore all your options on that one!

Also there are 3rd party tools from Veeam, Vizioncore and VKernel that might help and assist with this.

One thing I suggest is making a test VM of whatever server package you run. Update it, snap it, snap it again, try deleting a snap, etc etc. Thick to thin it, and then re-inflate it. Get totally comfortable with how the VM "lives" in the environment and then when you have an issue that pops up for real, you will already know how to react to fix it.

Hope this helps,

Hugh

http://www.1zero1.net