- Community Home
- >
- Storage
- >
- Entry Storage Systems
- >
- MSA Storage
- >
- MSA 2052 diskgroup and vmware
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-12-2018 12:01 AM
06-12-2018 12:01 AM
MSA 2052 diskgroup and vmware
Hi all,
I'm just trying to understand my new MSA 2052.
So i have just created a raid 1 with two SSD'S within Pool A and Raid 5 Volume also within Pool A Diskgroup for tiering purposes.
So the DIskgroup on Pool A has the total size of 24,1 TB = 2x Volumes ( Volume one = 20,9 TB and Volume two 3 TB)
Both Volumes are now mounted and formated on Vmware. And i have already lots of vmdks on that volumes. So theroreticaly on this diskgroup is no more space to create new volumes. But it seems that my MSA2052 can see how match is exactly in use under vmware and give me the possibilty to create new volumes with the free remain space which is not in use ander vmware yet. That is confusing me. If i gonna create a new volume now within this disgroup it will break all my vmware volumes i guess. Can someone explain me this behavior?
On my previous MSA P2000 system with linear vdisks it was pretty easy if you have a vdisk withs lets say 20 TB and two volunes on that vdisk with 15 TB and 5 TB no matter how much was in use or not you was not able to create any voluem on that vdisk.
Hope you can bring some light on that
Many thansk to all
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-12-2018 12:21 AM - last edited on 06-18-2021 03:17 AM by Ramya_Heera
06-12-2018 12:21 AM - last edited on 06-18-2021 03:17 AM by Ramya_Heera
Re: MSA 2052 diskgroup and vmware
P2000 G3 is Linear array which means any volume space is fully allocated space. Any volume space can be directly mapped from the vdisk in particular.
MS2052 is Virtual Array which means any volume created is thin provision volume. Here volume gets created from Pool and Pool created with single or multiple Virtual Disk Groups (VDG) similar to Vdisk in Linear array. So from Pool perspective you see only space.
When any new write happens at the ESX side then space gets allocated from MSA at the backend. There is no space gets pre-allocated like P2000 Linear array. So no wastage of space.
So in this case whatever space that you see at the time of creation of volume this is called provisioned space and not actual allocation of storage space. So you don't know from which VDG, volume actually got the space for creation or at time of data write space gets allocated. This is abstract and that's why this is Virtualization.
In order to understand more on this I would suggest to go through MSA2052 SMU guide and best practice technical paper.
https://h20195.www2.hpe.com/v2/Getdocument.aspx?docname=a00015961enw
https://support.hpe.com/hpsc/doc/public/display?docId=a00017707en_us
https://support.hpe.com/hpsc/doc/public/display?docId=a00017710en_us
Hope this helps!
Regards
Subhajit
If you feel this was helpful please click the KUDOS! thumb below!
***********************************************************************************
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-12-2018 03:24 AM
06-12-2018 03:24 AM
Re: MSA 2052 diskgroup and vmware
ok got it,
but the volumes are formated already within vmware so the whole space should be now alocated no matter how many vmdk's are on it. I guess storage shouldn't care about vmdks as vmware already has blocked the volumes by formating it as vmfs5. Or im wromg? I guess the should be un allocated space. I think only when i mount the volume in vmware as a raw mapped than i would understand this behavior but not as a usual vmware formatted volume.
Please sse the screenshot
Many thanks for helping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-12-2018 10:48 AM - edited 07-20-2018 03:09 AM
06-12-2018 10:48 AM - edited 07-20-2018 03:09 AM
Re: MSA 2052 diskgroup and vmware
You could have taken one MSA volume and share outputs of the below commands as i don't go by SMU output for better understanding,
show volumes
show disk-groups
show pools
Also you could have share screenshot of the same MSA volume in ESX host and how much space consumed in VMDK level or Datastore level
Most important when you try to understand space related stuff you need to check what is the base value set at MSA and ESX. Please refer SMU guide and section "Size representations",
"Operating systems usually show volume size in base 2. Disk drives usually show size in base 10. Memory (RAM and ROM)
size is always shown in base 2. In the SMU, the base for entry and display of storage-space sizes can be set per user.
When entering storage-space sizes only, either base-2 or base-10 units can be specified. Base 10 is the default."
In order to check this, you can use MSA command,
show cli-parameters
********************************************************************************************************************************************
In general whatever space you see as Allocated in MSA that means data written in that space in Pool level or VDG level but the space shows as Unallocated means volume not yet written data in it. So unallocated space related to volume level
If I take your example, in case of Pool B total size = 8990GB
Provisioned size of volume named archive-volume = 8989.9GB
Allocated size of archive-volume = 907.9GB
This means unallocated size at the volume level = (8989.9-907.9)GB = 8082GB [This space not dedicated for any particular volume, this can be use by any volume part of that Pool]
you can see free space = 8082.6GB and uncommitted space = 566.2MB
So free space is nothing but sum of unallocated space + uncommitted space which is coming from Virtual pool
Uncommitted space is the overall space minus the allocated and unallocated space.
Hope this helps!
Regards
Subhajit
If you feel this was helpful please click the KUDOS! thumb below!
***********************************************************************************
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-22-2018 12:16 AM
06-22-2018 12:16 AM
Re: MSA 2052 diskgroup and vmware
hmmm
ok lets try that this way please.
If you take a look at my screenshot you will see:
Virtual Pool A = 24,TB with two volumes on that ( Volume1= 20,9TB+ Volume2=2,9TB). I have mounted thos both volumes in VMware and formated with vmfs5.
Virtua Pool A = Alocated space 15.5 TB and Unulocated space 8,4 TB
I see the same now under Vmware = ( Volume1= 20,9TB+ Volume2=2,9TB) = free space on both together = 8,4 TB
So MSA showing me the same as Vmware, so that is fine.
BUT under VMWARE this both volumes size are constant
On MSA it looks like i still be able to create a volume with the unused space i see on my VMWRE as it showing me the unused space under vmware as unallocated space on MSA SMU.
What Im not sure about is can i now create a third volume with the unallocated space? If some i guess it will distroy my VMware volumes. I hope you know what i mean.
Many Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-22-2018 01:45 AM - edited 06-22-2018 03:45 AM
06-22-2018 01:45 AM - edited 06-22-2018 03:45 AM
Re: MSA 2052 diskgroup and vmware
Thanks for your confirmation that what you see in MSA exactly matching in ESX as well. So one part is done - this means both system base value set at correct value.
Now you need to understand what is Thin Provision volume that will clear all your doubts.
In MSA no one is stopping you to create third volume and that is not related or depend on how much unallocated space you have in the system.
You can create even 30TB volume with current condition eventhough you don't have that much space available in the system. This is the beauty of Thing provisioning. This means you have created 30TB provisioned volume - this means your volume can take space up to 30TB that doesn't mean you need 30TB space at the time of creation itself. In order to create a thin provison volume you just need some KB of size only. As in when you start writing data on it at the host filesystem level space will get allocated for that volume from Pool from which it got created at the backend.
Now anothing thing to make you understand, for any volume allocated space and unallocated space are committed space for that volume from the Pool from which it got created. This means if you have created 30TB volume then this is expected from that pool that it should be able to provide 30TB space to that volume. So Pool is committed to provide this much space to the volume. That's why unallocated space even though not yet allocated to the volume but this space committed to that volume. That doesn't mean committed unallocated space dedicated for any volume. Unallocated space in that Pool can be used by any volume part of that Pool.
Now any space which shows under uncommitted means this space part of the Pool but not required to be for any volume as unallocated space fullfil the requirement of committed space. Both uncommited space and unallocated space represents free space in the Pool.
So in your case if you really create any third volume with current condition and plan to use it then you can do so but make sure you closely monitor them and add more space to fulfill all volume commited space requirement as in when required.
In ESX if you see any MSA volume space.......this can't be fixed.......it must change........you can clearly see it...........you may be looking at the datastore screen only...........you need to explore more to see it properly
Hope this helps!
Regards
Subhajit
If you feel this was helpful please click the KUDOS! thumb below!
**********************************************************************************
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-22-2018 06:45 AM
06-22-2018 06:45 AM
Re: MSA 2052 diskgroup and vmware
Hi Subhajit,
yes I understamd that with the MSA thin provision space.
What still not clear is the VM datastore:
In ESX if you see any MSA volume space.......this can't be fixed.......it must change........you can clearly see it...........you may be looking at the datastore screen only...........you need to explore more to see it properly
I mean sure that is not fixed when i trasfer data on the vmware datstore i will have less availble free space. but When i mount a voulume to vmware i format that with a specific TB or GB amount, that is thick provisioned. An that formated capacity is not thin provision that is fix= thick.
That what i mean it can't be thin provision on msa and thick provisioned on vmware datastore
Hope that make sense?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-24-2018 11:31 AM
06-24-2018 11:31 AM
Re: MSA 2052 diskgroup and vmware
Ok now I got your doubt. Actually you are getting confused because you are seeing fixed space as formatted capacity inside VM or from Guest OS perspective. These are called thick disks, they behave similar to thinly provisioned disks. Disk blocks are only used on the back-end (array) when they get written to inside in the VM/Guest OS. Again, the Guest OS inside this VM thinks it has this maximum size from the start. There are two types of Thick disks in ESX apart from Thin disks and they are "Eager Zeroed Thick" and " Lazy Zeroed Thick". I would suggest to go through these concepts in VMWare - that will help you to understand more on this.
Hope this helps!
Regards
Subhajit
If you feel this was helpful please click the KUDOS! thumb below!
***********************************************************************************
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
