Upgrading vShield Manager 5.0.x – A Leap of Faith Upgrade
Having recently just completed the upgrading our vCloud Platform from 1.5 to 5.1 I thought it best to share my experiences around the upgrading of the vShield Manager Component of the vCloud Suite. There are plenty or reference articles out there on the on the general flakiness of the vShield Product and it certainly appears to be the least polished of the vCloud Suite.
In the ZettaGrid lab we spent the most time trying to successfully upgrade the VSM from version 5.0 to 5.1.2 (at the time of writing there is a version 5.1.2b available upon request) Between my colleague and I we where having little success in reaching a point after deploying the first 5.0 Maintenance Bundle whereby the VSM wasn’t throwing a kernel panic on reboot. Again, this seems to be a common issue with the vShield’s. Time with VMware support wasn’t resulting in any great leap forward…at this stage we where in a position where we might not be able to upgrade the platform.
After a week of so of trial and error, we came up with the following order of operations resulting in a successful upgrade. The Official VMware KB for upgrading to vCloud Network and Security 5.1 can be found here:
You will need the following packages:
Get access to the VM Console to verify your running version:
From here you can see we are working with version 5.0.2-791471 and that we have about 1.2G of free /common space which is relevant and why we need to deploy the maintenance bundles as part of the upgrade.
- Take SnapShot of VSM VM
- Shutdown VSM VM
- Update the VSM VM Configuration
PowerShell1(LEAP OF FAITH 1 - <span style="color: #ff0000;"><em>This step is suggested to happen after applying update, but if we didn't action this here, we would get a kernel error after applying the initial maintenance bundle</em></span>)
- 2 vCPU
- 8GB RAM
- Change OS Type to Other 64bit
- Change SCSI Controller to LSI Logic Parallel
- Run 5.0 upgrade maintenance bundle in order to free up the 2.5G required for the install – check by logging into VSM and running ‘show filesystem’
PowerShell1(LEAP OF FAITH 2 - <span style="color: #ff0000;"><em>This upgrade may look like it fails but it will free up the required space, you will get a 404 or 501 error back from the VSM Web Interface</em></span>)
- Deploy the 5.1.2 Upgrade Bundle
- Login as admin account
- Deploy the 5.1.2 Maintenance Bundle
PowerShell1(LEAP OF FAITH 3 - <span style="color: #ff0000;"><em>This can take some time to complete, the VSM will be pingable but the Web GUI can take up 20-30 minutes to initialize</em></span>)
- Deploy the 5.1.2 Maintenance Bundle
- Login as Domain Account and check overall status
- Check to see that the VSM has re synced with vCenter, if not reconnect and confirm Inventory Sync has occurred
- Backup current Configuration to FTP
- Take down the IP details of the VSM for the next step
- Power down VSM
- Deploy new VSM VM from 5.1.2 OVA
- Run ‘setup’ to configure IP address the same as the original VSM
- Configure FTP Backup location to be the same as previous instance
- Import the backup configuration
PowerShell1(LEAP OF FAITH 4 - <span style="color: #ff0000;"><em>This will take some time to complete, the VSM will be pingable but the Web GUI can take up 20-30 minutes to initialize</em>)</span>
- Re-Deploy the 5.1.2 Maintenance Bundle
- Test vShield Edge deployment and modifications
- Add vCNS license to vCenter. This is an important step as the old license becomes obsolete.
- Delete original VSM VM
These are the steps that worked for us in order to get a successful VSM upgrade. Key points to take away is that along the way through this upgrade you will see errors that make it look like it’s failed and then there are times where you need wait and wait for the system to come back in order to log into the GUI. Suffice to say, if you didn’t know what was happening you would potentially start to roll back the changes from the SnapShot and look to start from scratch. Have a little blind faith with this upgrade…it does get there…eventually.