1752681
Members
5275
Online
108789
Solutions
SOLVED
Hi,
Just got the responsibility for our MSA 2050 san.
I have some questions about the storrage.
B pool is right now "overcommited", it did have some TB free last day.
in Vcenter, i can see there should be about 6 TB
if i tjek the Volumes, attached to Pool B, i see there shoudl be 2.6 TB free (Size minus allocated)
how come i do get these 3 diffrent result? do i miss something?
/Anders
Overcommitted means you have assigned out more, in volume space, than you actually have in physical space in the SAN. This space is thin provisioned so you may not have actually used it yet but you have the potential to run out of physical space in an over committed scenario.
>From the MSA "free space" standpoint, this means how much actual space you have left in the pool. This is what you really want to be concerned about. When this number reaches zero then the array will not except any more writes and you'll be in a world of hurt.
>From a VMWare perspective, it has no idea what you are doing on the back end. Because of the ability to "over commit" you could have provisioned a 16TB datastore with only 5TB of actual space in the SAN. So, if I've used 4TB of that then VMWare will tell you that you have 12TB left and the MSA will say you only have 1TB. The MSA value is what we are more concerned about.
So, add up all your volume sizes from Pool B and see how this differs from the space actually present in the pool. You really don't want to be wildly over committed/provisioned unless you're doing it with a specific purpose in mind and you are going to stay on top of the storage running out on the MSA and purchase additional storage before you actually run out. I prefer to turn over commitment off on the Pools as a safety mechanism but there are some valid reasons for it.
Finally, if you've recently deleted a bunch of stuff from a datastore, VMWare will show that free and the storage might not. This is because a zero reclaim has not occurred. Zero reclaim is handled differently in different versions of VMWare so best to search the VMWare KB's for guidance on your setup (or call VMWare support).
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
>From the MSA "free space" standpoint, this means how much actual space you have left in the pool. This is what you really want to be concerned about. When this number reaches zero then the array will not except any more writes and you'll be in a world of hurt.
>From a VMWare perspective, it has no idea what you are doing on the back end. Because of the ability to "over commit" you could have provisioned a 16TB datastore with only 5TB of actual space in the SAN. So, if I've used 4TB of that then VMWare will tell you that you have 12TB left and the MSA will say you only have 1TB. The MSA value is what we are more concerned about.
So, add up all your volume sizes from Pool B and see how this differs from the space actually present in the pool. You really don't want to be wildly over committed/provisioned unless you're doing it with a specific purpose in mind and you are going to stay on top of the storage running out on the MSA and purchase additional storage before you actually run out. I prefer to turn over commitment off on the Pools as a safety mechanism but there are some valid reasons for it.
Finally, if you've recently deleted a bunch of stuff from a datastore, VMWare will show that free and the storage might not. This is because a zero reclaim has not occurred. Zero reclaim is handled differently in different versions of VMWare so best to search the VMWare KB's for guidance on your setup (or call VMWare support).
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
My understanding in a storage vmotion is that VMWare first copies the entire VM, verifies it's 100% good, and then deletes the source. So, it is possible you will need 2x the space to do the move (at least temporarily). If the VM has multiple vdisks then you might try doing an advanced storage vmotion and migrating the individual VMDK's one at a time. Before doing so, look at the available pool space, in the MSA, and confirm that the pool has enough free space for the individual VMDK you are moving each time. If both datastores are in the same pool, you might see a temporary reduction in free pool space during the copy but it should equal back out again after the move is complete.
Perhaps others, monitoring the thread, might have other suggestions but that's what I'd try.
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
Perhaps others, monitoring the thread, might have other suggestions but that's what I'd try.
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
Acording to this, i really dont have much space.
Im trying to see what really takes the space. but i cant find a soulution on that.
Hello,
My understanding for VMotion of VMs is you must also be aware of the datastores the VMs are on and where you are attempting to migrate to. For example if you are moving the VM from datastore1 you need to move to another datastore that is accessable in VCenter. As a best practice you should also not span datastores for a VM.
As mentioned, be sure you have enough space to do the copy. It does require enough space to copy and then create a new VM.
Cheers,
Shawn
I work for Hewlett Packard Enterprise. The comments in this post are my own and do not represent an official reply from HPE. No warranty or guarantees of any kind are expressed in my reply.
I work for HPE
According to your picture, you're in a world of hurt on Pool B and not in dramatically better shape on Pool A. It's not a problem if you use all of your pool space if your volumes are fixed size and fully allocated. However, if you are overprovisioned, and nearly out of space, then that is when bad things happen.
You have three different virtual disk groups in your Pool B "standard" tier that are different set sizes and, based on description may be different disk types and capacities. With this setup you will likely experience some performance issues. Ideally, all disks in a tier (standard, performance, archive) should all be the same speed and capacity and they should be added to the pool in set sizes that are consistent.
Also, according to your screen shot, you show 685MB free in your Pool B which is dangerously low if you are overcommitting. If you add up all of the volumes, you have provisioned from the MSA Pool B, are they more than the 10.6TB total size of the pool?
This is going to take some effort on your part. The question is are you just plain using more capacity than you have? If so, order some more disks. Or is the issue that you have deleted stuff that hasn't been zero reclaimed yet? Create a spreadsheet of all your data stores, what volumes those datastores use on the MSA, which pool those volumes are in, and columns for free and used space of the datastore as reported by VMWare.
We can try to help you make sense of that spreadsheet if needed but I think you'll start to get some answers by just going through the exercise yourself.
Best of luck
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
You have three different virtual disk groups in your Pool B "standard" tier that are different set sizes and, based on description may be different disk types and capacities. With this setup you will likely experience some performance issues. Ideally, all disks in a tier (standard, performance, archive) should all be the same speed and capacity and they should be added to the pool in set sizes that are consistent.
Also, according to your screen shot, you show 685MB free in your Pool B which is dangerously low if you are overcommitting. If you add up all of the volumes, you have provisioned from the MSA Pool B, are they more than the 10.6TB total size of the pool?
This is going to take some effort on your part. The question is are you just plain using more capacity than you have? If so, order some more disks. Or is the issue that you have deleted stuff that hasn't been zero reclaimed yet? Create a spreadsheet of all your data stores, what volumes those datastores use on the MSA, which pool those volumes are in, and columns for free and used space of the datastore as reported by VMWare.
We can try to help you make sense of that spreadsheet if needed but I think you'll start to get some answers by just going through the exercise yourself.
Best of luck
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
It might be worth a call into VMWare support to see if they can help you determine if the failed migration is consuming any extra space and how to roll that back.
You can also take a look at this article and see if you can get some help with zero reclaim
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.storage.doc/GUID-B40D1420-26FD-4318-8A72-FA29C9A395C2.html
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
You can also take a look at this article and see if you can get some help with zero reclaim
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.storage.doc/GUID-B40D1420-26FD-4318-8A72-FA29C9A395C2.html
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.