Storage
--
Questions
--
Followers
Top Experts
Benefits of thin provisioned storage array in vmware 5
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.
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.
Zero AI Policy
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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?
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?
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
ASKER CERTIFIED SOLUTION
membership
Log in or create a free account to see answer.
Signing up is free and takes 30 seconds. No credit card required.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
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.
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.
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.
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.
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.
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.
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
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.
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.
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.
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.
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.
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.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
Excellent answer
Storage
--
Questions
--
Followers
Top Experts
Computer data storage, often called storage or memory, is a technology consisting of computer components and recording media used to retain digital data. In addition to local storage devices like CD and DVD readers, hard drives and flash drives, solid state drives can hold enormous amounts of data in a very small device. Cloud services and other new forms of remote storage also add to the capacity of devices and their ability to access more data without building additional data storage into a device.