vHBA/vNIC desired order does not match actual order

[java_cat33]

Hi,

I've configured a vNIC placement policy with virtual slot 1 configured as "assigned only" and slots 2-4 left set to the default setting of "all".

The service profile template includes 8 x vNICs and 2 x vHBA's. All of the vNICS and vHBA's are assigned to vCON1.

The 2 x vHBA's have a desired order of 1 and 2 followed by the 8 NICS with an order from 3 - 10.

When I create a service profile from template however, the vNIC's have an actual order of 1 - 8 and the vHBA's have an actual order of 9-10.

I've re-created the template, re-created the service profiles but still can't get the vHBA's to an order of 1 and 2 followed by the vNICS.

Running UCS Manager 2.1 (3a)

Any help would be appreciated.

Thanks                

[Walter Dey]

No clue why UCSM changes the order; however, it is completeley irrelevant in which order you have vnics and vhba

[goapps.us]

Actually NIC order has a huge impact when virtualizing. So any additional guideline on how to actually set this predictably would be appreciated. 

Thanks 

[pedro.prata]

I have the same problem...

When I needed to add 2 more vNICs to the Service Template, after aplying the changes to one blade server, the Actual Order of both vHBAs changed and now it fails when It boot from SAN.

I even tried to change the Placement Policy to manual and setting the old order, but it ignores my changes and sets the vHBAs to the higher Order IDs (9 and 10, in my case, when they used to be 6 and 7).

Any help would be very appreciated.

[Walter Dey]

The ordering is done according to the PCI order.

This has the upgly effect, that if you add e.g. 2 additional vnic's to a existing config with e.g. 2 vhba's and 4 vnic's, the ordering is completely screwed up, as you describe.

depending of the OS, numbering of interfaces in the SP doesn't match the one the OS discovers.

This can be fixed, if you first delete all interfaces and start from scratch; yes I know, it might mean that vhba's get another wppn, and your zoning is screwed up. However, you might be lucky, and your vhba will pick up the same pwwn. (deleting vhba gives the pwwn back to the pool; I assume sequential alloaction).

I don't understand your statement about boot from SAN no more working ? Why ? vhba numbering in SP stays the same, same for pwwn ?

[pedro.prata]

Thanks for your reply.

I'm trying to add 2 new vNICs. If I add them both at once, the server won't boot (it's booting from SAN, as I mentioned before).

But, If I add one vNIC at a time (add new vNIC and boot the server, then poweroff and add the second one), the server boots and as far as I see, it discoveres and installs the vHBAs again (I'm assuming this since they both get installed with version 2.2.0.17 of the driver, instead of 2.4.0.8).

Something similar happens with the vNICs: they show up in Device Manager (using Windows 2012 R2) with a yellow icon and with a note that Windows can't start that device. I just delete the vNICs in this state, force a Scan for Hardware Changes and update the driver (vNICs also get installed with version 2.2.x of the driver, instead of 2.4.x).

As you said, pwwn stays the same. I've explained myself wrong: the machine starts to boot and after a few moments I get a BSOD with Inaccessible Boot Device error. If I had one vNIC at a time, it works.

[Walter Dey]

You are aware, that adding or removing virtual interfaces is disruptive (reboot of the blade); Sometimes it is cleaner after a config change, to do a disassociate / reassociate the SP.

I'm assuming this since they both get installed with version 2.2.0.17 of the driver, instead of 2.4.0.8

can you please clarify ?

- which UCS version are you running ?

- it looks like you would do a downgrade

- this is the enic driver ?

[pedro.prata]

Hi,

I'm using UCS 2.2(1c).

I had 2 versions of the vNIC and vHBAs on the servers. I managed to delete the older version (2.2.x) and now it doesn't downgrade the driver.

This happened both on the vNICs and the vHBAs.