We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you a podcast all about Citrix Workspace, moving to the cloud, and analytics & intelligence. Episode 2 coming soon!Listen Now

x

Benefits of thin provisioned storage array in vmware 5

totallypatrick
on
Medium Priority
174 Views
Last Modified: 2017-01-19
Hi experts, I have done some readings on best practices for VMware storage and what I have gathered is to use thin provisioning on the array side and thick on VMware side. I'm a little confused here. If I configure thin on the storage array what good does it bring in term of space savings if the VMware side is thick? For example, if a VM is provisioned for thick with either eager or lazy zero, all the space is given to that VM. Say we give 50gb to that VM, all of 50gb is reserved for that VM. If my LUN is just 200GB, whether is it thick (lazy or eager) , I'm still left with 150GB right? Or am I missing something here. Thanks. To me it makes no difference on the array side if we were to use thick on the VMware side.

I'm using IBM v3700 Storage Array. It does not support space reclamation which the high v7000 support. Should I still use thin provisioning or thick on the array? Many thanks in advance.
Comment
Watch Question

CERTIFIED EXPERT

Commented:
I'm not familiar with that specific array.  Assuming that it doesn't by default use a thin storage profile, then I always suggest making the VM itself thin, unless told not to by the primary use of the VM.  For example, if I was going to use that VM for a particular application and the manufacturer said that they support virtualization, but not a thin provision storage, I'd do thick.

Thin provisioning is not without it's issues.  For example, it's very possible to over provision your storage. If you have 1 TB of storage and you put 4 VM's on it with 500 GB each, that could potentially fill up to 2 TB - which obviously isn't good.  So you do have to keep an eye on how much real storage is left on any data store. The good side of the thin provisioning is that you can tell it you want 500 GB, but if you only end up using 200, then you've only really allocated 200.

We use Pure Storage flash arrays in our environment. By default they do thin storage as well as deduplication and compression. We still thin provision our VM's.

Author

Commented:
thanks for the input jhyiesla. The IBM v3700 supports thin provisioning but not space reclamation that are usually only found in higher end array. Actually all my current VMs are already on thick. My old storage is IBM DS3400 is also on thick. The v3700 is newly bought so I thought why not use thin provisioning on the array side to make better use of storage space.

To get this clear, I thin provision 500GB on the array side. On the VM side I assign up to 500GB (max) to the VMs (thick) but the actual space use is just 200GB combined, do the array just show 200GB used or the full 500GB?
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT
Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT

Commented:
I really can't accurately answer that since I don't use that array.  But I think that the way Pure does it should be similar.

On a VM, you allocate 500 GB of space and in a thin provisioned VM you can grow into that, assuming you have enough real space, but the actual amount of disk taken up is only as big as what you've installed on that VM's disk.

In the Pure array world, it's kind of the same.  Our scenario here is that we have 10 TB of real space. We have two LUNs that we created each at 20 TB; obviously that's more than we could normally store. But with the de-duplication and compression, we get around a 5-6:1 ratio. When I look at the array in the vSphere client I see 20 TB available for each array and then within that I see my various thin provisioned VM's showing what they're actually taking up as well as what they could go to. The Pure system shows what I've allocated to the LUN's, shows us the remaining real free space in GB and what percentage of the total 10 GB is still available.

There's no real problem with making everything thin, except for what I've outlined above. Some server installs don't want you to use Thin provisioning on the VM and you do have to monitor your real usage so that you don't run out of real space. I'd think that thinning the array itself would not affect anything adversely at the server level. And again, the only downside I see is monitoring the real free space.
CERTIFIED EXPERT