BladeSystem Virtual Connect
cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to upgrade VC firmware from 3.51 to v3.70

 
chuckk281
Trusted Contributor

Unable to upgrade VC firmware from 3.51 to v3.70

Abdul needed to upgrade some Virtual Connect modules:

 

****************

 

I am trying to upgrade VC Flex-10 firmware from 3.51 to 3.70,  but it is failing with the attached error, but I am able to upgrade to 3.60. But again from 3.60 to 3.70 I am getting the same error “ XML file format is invalid”  can anyone faced this issue ?,

 

I have around 30 enclosure need to be upgraded to 3.70. I am following SPP 2012-08-0.

 

***************

 

Input from Veera:

 

**************

 

Below are the some of the minimum prerequisite  for upgrading the VC firmware from 3.51 to 3.70. please check if are you using the vcsu utility version 1.7.x

 

Minimum Onboard Administrator firmware version required: 3.11

Minimum VCSU version required: 1.7.0

 

**************

 

Reply from Abdul:

 

****************

 

Thanks,

I was using VCSU version 1.5.2, I have downloaded VCSU Version 1.7.1 now up gradation is going on.

 

****************

 

Comments?

1 REPLY
chuckk281
Trusted Contributor

Re: Unable to upgrade VC firmware from 3.51 to v3.70

Chris also supplied some info:

 

****************

 

A few other points mostly driven by operational realities:

 

1.

SD/USB requires setup of separate scratch area in shared storage to have persistent logs and crash dumps.  This is an additional configuration step and needs to be remembered and documented.  Personally, I do not recommend SD/USB, as maintenance of this infrastructure does not align well with established server administration methods.

 

2.

BFS is great for large environments, where generally there is an experienced SAN administrator and they are able to maintain the BFS infrastructure.  BFS gives you wonderful flexibility, as the blades themselves keep no state other than BIOS settings.  In addition, there is a considerable saving in eliminating 2 physical local disks from each ESXi server.  If you have 200+ of these servers then this is significant capex that is eliminated.  The cost of shared storage allocated for BFS is insignificant, as this is only ~6 GB of RAID5 storage per host.

 

Also note that BFS is not an option when your shared storage is NFS only (e.g. NetApp arrays).

 

BFS from iSCSI arrays is possible with hardware initiators, but it rather complex to set up and maintain, so it does not mesh very well with the small scale of typical iSCSI installations and the way they are operated.

 

So, BFS is really only for FC SAN, I believe

 

3.

On the other hand, the mirrored pair of local disks is very simple to set up and the boot from it is very simple to maintain.  All server administrators are familiar with it.  It nicely decouples the boot problems from the configuration of shared storage.  I generally recommend this setup for smaller environments, especially the less sophisticated ones, where there may not be a specialized SAN administrator.  The simplicity of management compensates for increased capex.

 

4.

So my rules of thumb are very simple:

 

  • Auto-deploy                     - no, too complex for little benefit compared with BFS
  • SD/USB                                             - no, too awkward to maintain
  • Mirrored local disk          - yes, for small unsophisticated environments and where shared storage is NFS or iSCSI
  • BFS                                      - yes, for large environments with FC shared storage and good FC SAN skills

 

*****************