Resize VMFS based Esan datastore #296
Conversation
et1975
left a comment
et1975
left a comment
There was a problem hiding this comment.
The stated reason for this PR is not reflected in the implementation. If the intent is simply to add a version of "resize" function that takes datastore name then it should say so.
| throw "Datastore $DatastoreName does not exist." | ||
| } | ||
|
|
||
| if ($Datastore.Type -ne "VMFS") { |
There was a problem hiding this comment.
I believe the the test does not correspond to the conclusion - I don't see what's testing the VMFS provider specifically for Elastic.
There was a problem hiding this comment.
This is pointless and redundant to resize-vmfsdatastore.
There was a problem hiding this comment.
Hi @et1975 and @Zsoldier, thank you for taking out time to review the PR, I have renamed it to Resize-iSCSIDatastore, as we want it to available for both iSCSI-based storage solutions, ElasticSAN and Pure. It differs from Resize-VmfsDatastore in the way that
1.GA version of the package of Resize-VmfsDatastore is tied to Pure Storage GA. This GA version only allows customers to execute the cmdlets necessary for Pure Storage CBS appliance integration. Hence it can't be used for ElasticSAN use cases.
2. Customers might not have NAA ID readily available of the attached LUN, this will allow them to expand datastore using ClusterName and DatastoreName only,
adding same details in the PR description as well.
This check will ensure it is not implemented for other Datastore Types- vvol and NFS
| #> | ||
| function Resize-ElasticSANDatastore { | ||
| [CmdletBinding()] | ||
| [AVSAttribute(10, UpdatesSDDC = $false, AutomationOnly = $true)] |
There was a problem hiding this comment.
What automation is going to call this?
There was a problem hiding this comment.
This is pointless and redundant to resize-vmfsdatastore as that is designed to be called by automation only as well.
There was a problem hiding this comment.
Thank you for pointing out, I have removed AutomationOnly flag, we want this Run Command to be available for Customers on Azure Portal as we have been receiving numerous requests for support for Volume Expansion for Elastic SAN
|
I think if we want to offer to resize arbitrary VMFS via the portal and using the datastore name we should modify the existing function to take either ID or name parameter, making them both optional and validating in the implementation that at least one is specified. |
|
Hi @srajmohan24, can you provide your insight on @et1975 suggestion, is it feasible to use run command currently used by Pure for Elastic SAN as well with optional parameters. |
Yes, the existing |
Can this be triggered by Customer via Azure Portal as well ? Given it has AutomationOnly flag enabled as we want to give this functionality to our customers. |
We would need to remove the |
4 participants
This PR closes #
The changes in this PR are as follows:
We want to provide RunCommand based experience for ElasticSAN customers to expand their ElasticSAN datastore, once they expand their ElasticSAN volume in Azure Portal.
Creates a new module, and a new cmdlet Resize-iSCSIDatastore for expanding ISCSI based datastores for AVS.
The new Resize-iSCSIDatastore accepts ElasticSAN and Pure datastore name and cluster name to identify the datastore and expand it, internally we are calling Resize-VMfsVolume cmdlet
Screenshot of Testing -
Increased Volume size from 125 GB to 150 GB
Tested failure scenarios, gracefully handled
Tested again with changes from 100 to 120 GB