Using ESXCLI V2 to Configure Storage Multipathing
A customer recently came to me with the need to use ESXCLI to configure a bunch of storage settings on all of their ESXi hosts. He had been planning on connecting to the local console of each host and then executing the command, but wanted to know if there was a better way. Of course there is! We could use plink to run a script on his workstation that would establish SSH connections to his servers and then execute the ESXCLI commands... or we can do it all through PowerCLI!
I actually tackled this same problem 5 years ago using get-esxcli. At that point, I did it with the normal V1 version of the cmdlet, which required carefully spaced lists of parameters, leading to ugly lines like this: $esxcli.storage.core.device.set($thisLUN.CanonicalName,$null,$null,$queueFullSample,$queueFullThreshold,$null)
No more! Now, we have access to get-esxcli -v2, which is much easier to use! Instead of needing to put a bunch of $nulls into the .set() method to space out our values, we can use the .createArgs() method to create an object with named parameters! Then, we set appropriate values for each of those parameters and feed that object into an .invoke() method to set them! It sounds a bit complex, but it's pretty easy to understand once you see it in practice.
So, I put together this quick script to set the storage values that this customer needed. I built this script to target all of the hosts in his environment that were in maintenance mode, so that he could execute this script as he needed it. I included an additional -vmhost parameter so that he could use a regex to further limit the scope of the script, as well.
The script is pretty straight forward. It gets the list of target ESXi hosts, then goes through each one invoking the necessary changes via esxcli. The first thing that it does (after getting the ESXCLI for the host) is invoke the .createargs() method to create an object that contains all of the applicable arguments for that bit of ESXCLI. That's an extremely handy tool, because you can then look at the object that it generates to get an idea about what settings can be managed. Also, you don't have to mess around with getting them in the right order or counting out the nulls as place-holders!
So, the script takes that object and puts appropriate values in each of its parameters. After that, it invokes that object to set those values and is good to go! Pretty easy, right?
As always, this script is published as-is with no guarantees. Although it worked for me in my situation, that doesn't mean that it'll work for you in yours. Test everything you find online thoroughly and make sure that you fully understand what it's going to do before executing it in your environment!
I actually tackled this same problem 5 years ago using get-esxcli. At that point, I did it with the normal V1 version of the cmdlet, which required carefully spaced lists of parameters, leading to ugly lines like this: $esxcli.storage.core.device.set($thisLUN.CanonicalName,$null,$null,$queueFullSample,$queueFullThreshold,$null)
No more! Now, we have access to get-esxcli -v2, which is much easier to use! Instead of needing to put a bunch of $nulls into the .set() method to space out our values, we can use the .createArgs() method to create an object with named parameters! Then, we set appropriate values for each of those parameters and feed that object into an .invoke() method to set them! It sounds a bit complex, but it's pretty easy to understand once you see it in practice.
So, I put together this quick script to set the storage values that this customer needed. I built this script to target all of the hosts in his environment that were in maintenance mode, so that he could execute this script as he needed it. I included an additional -vmhost parameter so that he could use a regex to further limit the scope of the script, as well.
The script is pretty straight forward. It gets the list of target ESXi hosts, then goes through each one invoking the necessary changes via esxcli. The first thing that it does (after getting the ESXCLI for the host) is invoke the .createargs() method to create an object that contains all of the applicable arguments for that bit of ESXCLI. That's an extremely handy tool, because you can then look at the object that it generates to get an idea about what settings can be managed. Also, you don't have to mess around with getting them in the right order or counting out the nulls as place-holders!
So, the script takes that object and puts appropriate values in each of its parameters. After that, it invokes that object to set those values and is good to go! Pretty easy, right?
As always, this script is published as-is with no guarantees. Although it worked for me in my situation, that doesn't mean that it'll work for you in yours. Test everything you find online thoroughly and make sure that you fully understand what it's going to do before executing it in your environment!
Comments
Post a Comment
Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,