how do we create a thick ldev on VSP
This is one way to create thick LDEVs from Storage Navigator:
thanks Dang for the info
*** Moved discussion to The specified item was not found. and added Storage category
You can create two types of LDEV in VSP, a Basic LDEV, that's the classic physical LDEV bounded to one parity group or pg-concat, or a Dynamic Provisioning LDEV, bounded to a Dynamic Provisioning pool composed of many stripped parity groups. Dynamic Provisioning also uses thin provisioning allocation.
To create a Basic LDEV, you can follow the Dang Luong previous procedure, and that will be 'thick' LDEVs.
But, instead of creating physical LDEVs in selected PGs, you can configure a DP Pool with subscription = 100% from GUI or CLI (raidcom modify pool -pool <N> -subscription 100). The thin algorithm will be used, but enforcing that no more than 100% of real pool capacity could be defined. That gives you the assurance of no overprovisioning shortages in critical systems with the advantages of DP performance, growing and striping.
for me.. i am not concerned about the over provisioning.
i am concerned about the space when i allocate to ESX cluster.
thats the reason i was looking to allocate thick/basic ldev to ESX so that they wont waste storage.
i was given the same direction from support as Dang, but i was wondering whether any chance to create a thick ldev from a pool level so that i can utilize "n" disks residing in a pool.
Yes, Dang's and support's procedures are correct, that's the answer to 'create a physical ldev'. But my question was, do you really need a physical/thick LDEV ?
When you create a VDEV in a HDP pool, it uses all spindles but allocates only the used blocks. A physical LDEV will alocate always the whole space, also distributed in all PG disks.
Thin provisioning is not related to disk count, you can think HDP pool as a big striped parity group, with the extra functionality of thin provisioning (allocation on demand), dynamic tiering, etc
I don't know what you mean with concerned about space, any LDEV uses at most the defined size, with VDEV the space is allocated on demand, with physical LDEV at once. So, a physical LDEV will claim all defined space at creation and waste it if not fully allocated.
Using at most n disk is more related to performance than space. If you want to avoid load concurrence, probably you need to plan more than one HDP pool to isolate workloads.
Anyway, if you really want a physical LDEV bounded to N known physical disks, the Dang's procedure is the only way.
we are going with thick ldev because, when i allocate 2x1tb ldevs.
and my win admin create a VM (vm1) on one of them lets say about 500gb..now when he move that vm1 from ldev1 to ldev2.
the blocks are not getting released.
so from his side, he sees only 500gb free on ldev1 rather than 1 tb.
thats the reason we were planning to go to thick provisioning.
even HDS suggested the same at VMWorld
In your 2x1TB scenario, are these DP volumes? If so, that is normal behavior. Even though VMware have moved the files, the blocks are still allocated from the array's perspective. In order to get the 500GB back to the pool, you have to tell the VMware server to release the blocks.
Please see this link from VMware: http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2014849&sliceId=1&docTypeID=DT_KB_1_1&dialogID=969080493&stateId=1%200%20969268040.
It's not possible to share pool volumes for any other purposes.
Unless you mean share a parity group that has volumes configured as pool volumes but still have some free capacity. Technically, that is possible. You can create new volumes from the free capacity and map them to hosts. However, this isn't recommended. The pool's performance will be impacted because the underlying drives are now shared with multiple hosts.
Retrieving data ...