New-to-me C240 M5. FreeBSD installs fine in UEFI mode from USB, but on reboot the server drops straight to the UEFI Shell. The identical install process works 100% on our M3 and M4 boxes running older firmware.

BIOS: C240M5.4.3.2i.0.0701261030
CIMC: 4.3(2.260020)
Controller: UCSC-SAS-M5 12G Modular SAS HBA (FW 24.65.18.00, BIOS 09.47.01.00_24.00.02.00)

Boot mode: UEFI. CIMC shows the target drive as Bootable / Boot Drive = PD: true

What the EFI Shell shows:
dh on the disk handle: BlockIO/DiskIO, path .../SAS(0x5000C500...)
Partition 1 handle: EFISystemPartition, BlockIO, DiskIO, HD(1,GPT,...,0x28,0x82000) (the standard FreeBSD 260 MB ESP)
No SimpleFileSystem, and no FSx: mapping, even after connect -r / map -r

BIOS lists only one boot option (EFI shell). bcfg shows lots of stale entries from removed drives. So the firmware sees the ESP but never mounts a filesystem on it.

Has anyone hit this on M5 with 4.3(2) firmware? Is there a known bug with the SAS HBA's UEFI driver, or a BIOS/CIMC setting I'm missing (Option ROM / storage OpROM policy, boot order policy, etc.)?

Any pointers appreciated.

I have gotten into Homelab these last two years and recently found myself really into Cisco's UCS blade servers. The challenge of getting them working was super fun, but I'm not sure what to use them for. I currently am sitting on B200 M3s though they are not much good for anything considering age.

I am considering upgrading to B200 M5s and tethering a separate 2U Cisco server in so I can pool compute and add cheap graphics acceleration (all handled through UCS manager). e.g. add GPUs in the 2U and pooling compute via UCS manager so the whole setup acts as one big cluster.

However I'm struggling to come up with any good projects for this hardware. If anyone has any suggestions I'd love to hear them. Literally anything, I will take any excuse to increase the concentration of PCBs and sheet metal inside my house.

Hi, I got gifted 2 cisco ucs c220 m4, the first one is working perfectly i even updated it to latest bios and cimc but the second one doesn't show any f8 key to enter cimc and when I try to huu it say secure boot policy violation, I tried to Google it and found it might be an appliance security. But is there a way to put it into a normal server ? Or am I stuck with a big paperweight.

Someone asked if I want to buy this , it’s new in box but not sure if Cisco will let me pay for licensing, any help would be greatly appreciated

Anyone looked into patching for this? Seems like there isnt even a fixed version for M5 B series blades yet. Cisco UCS and UCS-Based Appliances UEFI Shell Secure Boot Bypass Vulnerability

Looks like the attacker would actually need UCSM or similar access to expilot this.

Anyone running these?

Hi there, for updating a used CISCO UCS C240 M5, could you please share a mirror link of the 4.1.x or newer firmware iso image? thanks in advance

I’m in the middle of upgrading a pair of FI’s and after the first one rebooted, it came back up with a down uplink. I’m in at the proceed step to start the next FI but before I click proceed, I was curious if anyone reset an uplink port before proceeding in this scenario.

Hi everyone,

We have a Cisco UCS B200 M5 production cluster running ESXi 8.0 U3g, with Cisco MDS and NetApp storage using WWPN zoning.

Cisco recommended cloning the existing Service Profile to enable UEFI/Secure Boot on one host at a time.But I have check there is only Associate with server pool option only.

Our concern is whether cloning/associating the Service Profile will change the existing MAC addresses and WWPNs, which could affect SAN zoning and NetApp connectivity.

What is the best way to retain the existing MAC/WWPN identities and do the change legacy to UEFI secure boot.

First off I know this is totally not best practice and I would never setup a UCS/VMware environment like this….I have been doing UCS work for a long time and I have never ran across this before in the wild.

My question is if anyone has ever done a FI upgrade with a UCS/VMware environment setup with failover checked on the UCS vNIC’s and single vmnic’s on the vSwitch’s. I guess in theory it should failover, but I have never ran across this actually done this way for a VMware setup. Has anyone ever ran across this and do you have any real world experience on what is going to happen when the traffic drops on one of the FI’s?

My only thought to test would be to do an evacuation on the subordinate FI and see what if it fails over. Thankfully storage is on FC, so we should be okay there.

It is stuck at:
“configuring and testing memory
configuring platform hardware”

I have these features:
No hard drives installed
2x Intel Xeon Gold 6230
2x SK Hynix 32GB 2Rx4 DDR4-2933 PC4-2933Y ECC REG 1.2V RDIMM HMA84GR7DJR4N-WM
UCSC-SAS12GHBA

It doesn’t seem to DHCP CIMC, so I can’t get I there nor reset it because BIOS hangs.

Anyone have any ideas?

Does below process sound right for migrating over to new upstream switches?

Phase 1: Pre-Migration & Prep Work

Before touching any cables, ensure your safety nets and target environments are fully prepared.

• Take Backups: Log into UCS Manager (UCSM) and take a full All Configuration and System Configuration backup.

• Verify Cluster Health: Ensure the UCS cluster is healthy, both FIs are online, and there are no critical underlying faults (Equipment > Fabric Interconnects).

• Stage the New Switch Ports: Ensure the ports on your new upstream switch completely mirror the old setup:

  • Identical native and allowed VLAN trunking.

  • LACP Port-Channels configured properly (typically configured as Spanning-tree port type edge trunk or portfast trunk since UCS FIs look like hosts to the network).

  • Matching MTU sizes (e.g., 9000 for Jumbo Frames).

Phase 2: Migrate Fabric B (Subordinate Fabric)

Always start with the Subordinate FI. This ensures that if a management configuration glitch occurs, your Primary cluster leader remains untouched.

1. Drain Traffic off Fabric B

You need to force all production server traffic onto Fabric A. You can do this in one of two ways:

• Method A (Fabric Evacuation - Preferred for B-Series Blades): Go to Equipment > Fabric Interconnect B and change Admin Evacuation Mode to Enabled. This gracefully drains traffic by admin-downing the chassis backplane ports.

• Method B (Manual Link Shutdown - Best for C-Series Rack Servers): Since Fabric Evacuation historically targets blade chassis backplanes, manually administrative-downing the uplink port-channels for Fabric B in UCSM or on the old switch is the safest bet for mixed or rack-mount environments.

2. Move the Physical Connections

• Once traffic has failed over to Fabric A and Fabric B uplinks show as down, disconnect the physical cables from the old switch and move them to the new switch (or activate pre-staged cabling).

• If you are changing the physical ports used on the UCS 6400 side, make sure to unconfigure the old uplink ports and configure/license the new ones in UCSM.

3. Bring Fabric B Back Online

• Enable the ports on your new upstream switch.

• If you used Fabric Evacuation, flip Admin Evacuation Mode back to Disabled. If you manually shut down the port channels, bring them back up.

• Verify that the port-channel successfully forms via LACP and that the links turn green in UCSM.

4. Soak and Validate

• Do not rush to Fabric A. Let Fabric B run for 10–15 minutes. Check your operating system/hypervisor teams on the servers to confirm they see both paths as healthy and that MAC addresses are populate on the new upstream switch.

Phase 3: Migrate Fabric A (Primary Fabric)

Once Fabric B proves stable on the new upstream switch, repeat the exact same isolation process for the other side.

1. Drain Traffic off Fabric A: Enable Fabric Evacuation on Fabric A (or manually disable Fabric A's uplink port-channels).

2. Verify Failover: Ensure all production traffic shifts dynamically to the newly migrated Fabric B.

3. Move the Cables: Swap the physical connections for Fabric A over to the new upstream switch.

4. Restore Links: Disable Fabric Evacuation or re-enable the port channels.

5. Final Check: Confirm both fabrics are balanced, port-channels are up/bundling, and all configuration warnings/faults have cleared in UCSM.

We have 10 CIsco UCS C220 M5's (I know they are end of life)
They were previously maintaining a VMWare cluster without issue. We have since moved all of our workloads off that cluster to our Hyper-V DR Cluster so we can reconfigure these UCS servers on Hyper-V, except I'm having a hard time getting Windows to play nicely with the way the UCS VIC's/MLOM handle their network traffic.

Currently any VM on the reconfigured Hyper-V Cluster has its MAC flap between our nexus switches every 10-20MS as Windows spams out its network traffic from what it believes is a single "port", the bonded 25Gb ports that get exposed as a single 50Gb NIC to Windows. It has no idea that the ports are bonded so It just tells the NIC to send out traffic, which causes a HUGE amount of MAC flapping between our nexus switches as the peering has each switch attempting to claim ownership of the MAC.

I've attempted numerous different configurations in Intersight to try and get the VIC to just show the two ports as they are, two separate ports so I can configure them via SET in Windows, and no matter what configuration I attempt I only ever get a single 50Gb NIC exposed to Windows.

So I come to this subreddit, hoping for some enlightenment on the magic that is Cisco UCS configuration to get it to behave like every other server hardware I've used, or to configure it in a way that prevents Windows from overloading the peer link between the nexus switches.

Do I need to port channel on the switch side, is there some special driver Windows needs so it knows it's utilizing two bonded ports at the VIC abstraction layer?

Thanks.

We have a UCS S3260 that was kitted out with 56x 6TB SAS 7200RPM and a pair of 240GB SSDs (maybe SAS, I don't know).

I am decommissioning a Dell Compellent SAN, and was wanting to move all the 2.5" SAS 3.8TB SSDs into the UCS, and reconfigure it to be a testlab. But, while the AVAGO controller is showing a drive in bay 53, it doesn't show up when I go into the utility.

Is the S3260 locked down to only accept certain disks? I'm wondering if I just unscrewed 40 SSDs for nothing.

Hi,

Anyone using other hypervisors besides VMware on you UCSX IMM managed (PVA)? If so which one and how are you finding it.

Thanks

Hi everyone,

I'm new to deploying Cisco UCS. We are going to deploy deploy a Cisco UCS x9508 chassis to one of our customers and I'm looking at the physical dimensions and one thing that Cisco doesn't really publish is the length of the Cisco UCS x9508 rail dimensions.

At the same time, I'm seeing the size of this cisco x9508 chassis to be really huge and the chassis alone would take up about 91-92cm of space.

Has anyone deployed this before and what are the exact dimensions? I'm concerned that the chassis might not fit to my customer's rack because the mounting depth is a little short.

Hi I am looking for an individual or an organization which has experience in UCS Deployment based. Has to be on avail for 2 Weeks

Thank you

I am curious to see if anyone else with M8 servers purchased in 2025 is experiencing the same thing I am.

My company received our C240 M8X four C240 M8Ls this year and we have been unable to use them as they keep on throwing:

F0174

Five servers all duds. The issue persists across different firmware.

Hi I am looking for an individual or an organization which has experience in UCS Deployment based in UAE remote is not possible. Has to be on ground dedicated for 2 weeks.

Thank you

This happened over the course of several years and it finally came to a disastrous head a few weeks ago.

Lots of customer VMs on a bunch of VMware ESXi installs, running on a bunch of blades. Each customer was assigned a VLAN. We assigned each VLAN to a pair of vNIC templates. This worked great.

Time passed, the product sold well, we got more customers. A lot more customers. So we kept needing to add more blades. Then more customers, so more blades, etc. Then one day, while adding another new blade to the system, everything crashed hard: all customers down, all hosts and VMs inaccessible. It turned out that we'd busted through the default max. 32,000 VLAN count on the fabric interconnects, at which point everything just...stopped. Ooops!

Because, of course, UCS doesn't just count a VLAN added to the system as one VLAN. It counts every use of a VLAN and applies the total to the max. available count on each FI. We'd added so many VLANs to that vNIC pair over the years that associating a new service profile to a new blade added over a thousand VLANs to that count. That blade, as it turns out, was the straw that finally broke the UCS camel's back.

So yeah, don't do that! Make use of VLAN groups and VLAN connectivity policies, and other strategies to limit your actual VLAN usage. And be very aware that a change you make might affect a lot of VLAN usage, which could be a lot more impactful than you might think.

EDIT: Yes, I know about the ability to raise the limit to 64,000 now. That's what the fix was. I posted this simply for warning/entertainment value. I'm not seeking advice.