|UPDATE: HyperFlex v5.01b HAS FIXED THIS PROBLEM – Do not run this fixer if you are installing 5.01b or later. Somebody at Cisco must have read this blog!|
I was shocked the other day to learn that the hx_post_install script that is used during the Cisco HyperFlex install process does NOT work the way it should.
In fact, the validation option is a complete waste of time (if working with M5 servers, which is probably 90% of installations), as I reported here.
To fix it, I could create a new copy of the script and give that to you, and you could copy that to your HyperFlex Storage Controller VM, but that’s a pain. Instead, I’ve decided to give yo a few commands to run that you can cut and paste into a command shell to fix the problem – or at least work around the problem until Cisco fixes it. To ease the pain, all you need do is cut-and-paste the following into your ssh session on the storage controller – IF you have blind faith in my skills. Otherwise, you might want to go through it step-by-step, so you understand it.
Non-nonsence cut-and-paste answer
Cut-and-paste the following into your ssh session on the storage controller. (Note: With HX v4.5(2) and later, run this script from the Hyperflex Installer VM – it can’t be run from the storage controller VM because Cisco has restricted access to the root system on the SCVM in 4.5(2+)
cp $(which hx_post_install) .
sed -i 's/vmnic1/rednectar4/g' hx_post_install
sed -i 's/vmnic2/rednectar1/g' hx_post_install
sed -i 's/vmnic3/rednectar5/g' hx_post_install
sed -i 's/vmnic4/rednectar2/g' hx_post_install
sed -i 's/vmnic5/rednectar6/g' hx_post_install
sed -i 's/vmnic6/rednectar3/g' hx_post_install
sed -i 's/rednectar/vmnic/g' hx_post_install
sed -i 's/and args.validate//' hx_post_install
sed -i "s/Select post_install/***RedNectar's Updated hx_post_install script M5 modifications have been applied.***\\\nSelect post_install/" hx_post_install
sed -i 's/SCRIPT_VERSION = "4.0"/SCRIPT_VERSION = "4.1 RedNectar"/g' hx_post_install
echo "To run the modified script, type: ./hx_post_install --validate"
The first step after establishing an ssh session to a storage controller VM (or installer VM – esp v4.5(2+) ) is to locate the hx_post_install script
admin@hxscvm1:~$ which hx_post_install /bin/hx_post_install
Using the result of the output above, copy the script to your admin home directory (where you land when you start your ssh session) and check that it exists.
admin@hxscvm1:~$ cp /bin/hx_post_install .
admin@hxscvm1:~$ ls -lh
-rwxr-xr-x 1 admin springpath 92K Sep 17 10:42 hx_post_install
- Don’t miss the period at the end of the first line.
- If you wanted to be fancy, you could combine step 1 &2 with:
cp $(which hx_post_install) .
Now comes the bits where you manipulate the copy of the file using sed. Basically, you have to swap the vnic names from the order used in the old M4 servers to the new order used by the M5 servers according to the table below:
|vSwitch||M4 vmnics used||M5 vmnics used|
|vswitch-hx-inband-mgmt||vmnic0 vmnic1||vmnic0 vmnic4|
|vswitch-hx-storage-data||vmnic2 vmnic3||vmnic1 vmnic5|
|vswitch-hx-vm-network||vmnic4 vmnic5||vmnic2 vmnic6|
|vmotion||vmnic6 vmnic7||vmnic3 vmnic7|
The problem is of course that if you replace say vmnic1 with vmnic4, when you later replace vmnic4 with vmnic2, you’ll be replacing the things you just replaced, so you need a double pass over the file. Since I’m pretty sure the word rednectar does not occur in Cisco’s script, I’ll use that character pattern as a temporary placemarker for the word vmnic and then replace all occurrances of rednectar with vmnic at the end.
admin@hxscvm1:~$ sed -i 's/vmnic1/rednectar4/g' hx_post_install
admin@hxscvm1:~$ sed -i 's/vmnic2/rednectar1/g' hx_post_install
admin@hxscvm1:~$ sed -i 's/vmnic3/rednectar5/g' hx_post_install
admin@hxscvm1:~$ sed -i 's/vmnic4/rednectar2/g' hx_post_install
admin@hxscvm1:~$ sed -i 's/vmnic5/rednectar6/g' hx_post_install
admin@hxscvm1:~$ sed -i 's/vmnic6/rednectar3/g' hx_post_install
admin@hxscvm1:~$ sed -i 's/rednectar/vmnic/g' hx_post_install
Now that should take care of the bug – but there is one more annoying flaw with the script that I’d like to clean up too. And that is the fact that if you run the script without using the –validate option, it still asks you if you want to run a health check – BUT THEN DOESN’T DO THE MTU check.
So, to make the script ship-shape, add one more change to remove the logic that skips the test if the –validate argument was not specified:
admin@hxscvm1:~$ sed -i 's/and args.validate//' hx_post_install
Great, but you’ll also want to know you are running a version of the script that has been updated, so finish with:
admin@hxscvm1:~$ sed -i "s/Select post_install/***RedNectar's Updated hx_post_install script M5 modifications have been applied.***\\\nSelect post_install/" hx_post_install
admin@hxscvm1:~$ sed -i 's/SCRIPT_VERSION = "4.0"/SCRIPT_VERSION = "4.1 RedNectar"/' hx_post_install
And you are ready to run, BUT you’ll need to be careful that you run the copy that you’ve just edited, so in the same directory, instead of issuing the command hx_post_install, you’ll need to put the location path (i.e. ./) as part of the command – so enter:
***RedNectar's Updated hx_post_install script M5 modifications have been applied.*** Select post_install workflow- 1. New/Existing Cluster 2. Expanded Cluster (for non-edge clusters) 3. Generate Certificate Note: Workflow No.3 is mandatory to have unique SSL certificate in the cluster. By Generating this certificate, it will replace your current certificate. If you're performing cluster expansion, then this option is not required.
And of course, from now on you can just use the modified script by typing ./hx_post_install at the admin@hxscvm1:~$ prompt.
WARNING: If you started your session to the cluster IP address, then you need to remember which controller VM actually serviced your session, and make sure you have a session with the same controller VM before you try the ./hx_post_install version of the command.
Happy HX Installing