good day everybody
I am going to extend a datastore on vmware 6.7 to span multiple storage.
is it a stable solution with a good performance or can it cause performance issues
Thanks for your support
> I am going to extend a datastore on vmware 6.7 to span multiple storage.
Do not expand datastores using that procedure.
In case you ever need support for a recovery operation you will severely reduce your chances.
Just forget about expanding datastore with extends - the procedure is dumb - undocumented , changes from version to version and is not well thought out.
Performance wise it is ok - but as soon as enter a bad weather period performance is suddenly an uninteresting parameter.
Just use more datastore instead - thats the way to go.
Ulli
Just a small little fun fact:
assume you have 3 physical disks each of a size of 2TB.
So parent vmfs + 1st extent + 2nd extent builds a 6TB datastore.
Now assume you used thin provisioned disks and lose the first 4GB of the parent VMFS after a trivial powerfailure.
=========================================================================
Result is complete garbage - with luck you may be able to recover one or 2 VMs that had the luck to have been created before the expand.
Ulli
Yes, you can extend your existing VMFS using multiple LUNs.
Thanks for your reply.
I was asking about its stability in the production, can it have any performance impact.
If both underlying LUNs are of the same tier (same performance), you can do this, and you should not notice performance issues due to the extent. Personally I avoid extents since the time VMware started to support LUNs > 2TB.
Please note that ESXi will do no load balancing between the LUNs.
André
> I am going to extend a datastore on vmware 6.7 to span multiple storage.
Do not expand datastores using that procedure.
In case you ever need support for a recovery operation you will severely reduce your chances.
Just forget about expanding datastore with extends - the procedure is dumb - undocumented , changes from version to version and is not well thought out.
Performance wise it is ok - but as soon as enter a bad weather period performance is suddenly an uninteresting parameter.
Just use more datastore instead - thats the way to go.
Ulli
Just a small little fun fact:
assume you have 3 physical disks each of a size of 2TB.
So parent vmfs + 1st extent + 2nd extent builds a 6TB datastore.
Now assume you used thin provisioned disks and lose the first 4GB of the parent VMFS after a trivial powerfailure.
=========================================================================
Result is complete garbage - with luck you may be able to recover one or 2 VMs that had the luck to have been created before the expand.
Ulli
Hi, @SSATTY thanks reply me and @continuum and @a_p_ give very good reply.
For performance, every LUNs in a VMFS must be same performance.
Good case: LUN1 (SSD based) + LUN2 (SSD based)
Bad case: LUN1 (SSD based) + LUN2 (HDD 7.2K)
When you try concatinate different types LUN into single VMFS, you can and vSphere user interface will not make warning for it. So user must be careful for it.
And the "1st LUN" will be master extent for the concatinated VMFS. 1st LUN has metadata for the concatinated VMFS, so when it will be failed, the VMFS will be entired offline. (Before, we could see the information on VMware docs or VMware KB, but now I could not find it...the post may be archieved.)
And I have a question to you, recent storages has "LUN expansion" on itsself feature, that is support LUN resize for increase.
A storage: totally 10TB capacity.
LUN 1: 1TB
Then, 9 TB is free space, so the LUN 1 can be expanded from 1TB to up to 10TB. This way is recomemmded way by VMware than multi-extent because easy to manage the VMFS.
Yamato - I asuume your somehow involved with setting Dell environnments for customers - right ?
Would you recommend extents to cusomers ?
Would you recommend it to friends ?
I know it is officially supported but once you understand a little bit how it works all red flags pop up here .
Do you know a person that would repair a lost connection to an extent ?
I think we should not recommend procedures that dont make any sense in theory ?
WE should also not recommend procedures we dont want to see on our workbench one day.
For me there is only one conclusion: using extents ends in tears one day
Ulli