We would like to begin planning our upgrade to ESXi 6.7 and continue to use our existing investment in our B200M3 series. I go on Cisco's HCL list page https://ucshcltool.cloudapps.cisco.com/public/
put in B Series, B200 M3s, Intel Xeon E5 2600 Series, VMWare, but I see everything from ESXi 4.1U2 to 6.5U1. I didn't see 6.7 listed. If I change the processor to Intel Xeon E5 2600 Series v2, I do see it listed as supported.
So then I go to VMWare's site HCL page https://www.vmware.com/resources/compatibility/search.php?deviceCategory=server&details=1&partner=146&releases=369&keyword=E5-2600&systemTypes=1&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc
I see E5-2600 supported, I am confused so I call Cisco and VMWare. The best that TAC would do for me is open a enhancement request CSCvj31548. I don't see E5-2600 being desupported in the release notes for ESXi. Also I don't know it different from v1 to v2 and why it wouldn't be supported? The B200 M3s are still supported till 12/2021, but it seems like they are not. I see competing products with the same processor being supported on VMWare as well.
This isn't first time Cisco has does this with UCS, years ago they did it M81 cards in B200 M2s.
I just feel Cisco does a poor job of letting customers know that their gear isn't getting supported anymore despite EOSL is years away. Sorry about the rant, I just want to find some answers.
Thanks for posting. I completely understand your concerns here. Let me see if I can find out more info for you.
I'll do my best to get you close to an answer or to understanding this.
1) The word 'support' needs defining here. Support in this context means that we've tested a particular setup and will assist up to and including working in-depth via TAC cases, opening a defect, engaging the business unit and developers etc. Running outside of the support matrix will get you best effort support, that will depend on the individual engineer's schedule and time. You may already be aware of this but I need to level set. If this were a dev or testing environment and performance or reliability are not paramount for example, running the upgrade would be a fine option, for a production domain, not so much.
2) The HCL is variable, it changes over time, missing items will be added, items will be redacted, it will evolve as we go. There may already be plans to test and support your setup but they have not concluded testing yet. The enhancement defect that was open will ensure that the developers at least analyze that situation, that's honestly the best possible thing that we can do for you from TAC, along with encouraging you to engage your account team to help press that defect forward.
3) Cisco vs VMware's HCL. Cisco's is the source for truth here. We test our products to ensure that they function and perform to our high standards, if they do not they will not be certified. The way to approach this is generally to head to one or the other HCL, verify whether or not your setup is supported, then double check against the other. We do work with VMware to an extent but are not in lockstep on this, their testing standards or practices may differ for example, there could be any one of a hundred reasons why this is the case.
Finally, the last day of support which for this platform/CPU is in 2021, this server and CPU haven't been sold to the general public since June of 2016. With so many hardware products and OS versions available, this particular config may not receive the same attention in driver creation and testing as the brand new M5 servers with the newest OS flavors. It makes sense as unfortunate as that may be. This goes back to my second point above, testing may be taking place in the background or the plan for it may be coming along. VMware's release dates will not align with ours for every product, especially one deeper down the product line.
All of this was meant to pull back the curtain so to speak and offer some perspective which I hope was helpful to you. So in summary, I support TAC's decision to open that enhancement defect for you, I would reiterate that your account team can be helpful in moving that defect along as well.
In the meantime, a question that I have would be this, what feature or defect are you actively attempting to avoid that requires 6.7 at this time? That information is extremely helpful for your account team to know. If they present a business case for support for that particular OS version, they can gain traction on a defect that way as well.
Thanks! Again I do hope that this was helpful! Reach out with any questions.
I too will try to help guide what is occurring here.
VMware has documented for many, many years that when it comes to any IO support on their OS, that you should follow the 3rd Parties Interop Guides and not VMware's: https://kb.vmware.com/s/article/2030818
IO is obviously network and storage - or looked at differently - the foundation of all communication/storage in what their product does and the primary two things that their product virtualizes (that may or may not be a test question for Vmware's exams).
VMware also doesn't do any testing of specific products prior to putting them in their HCL. They look at the specs of the HW product and say (paraphrasing) "It should work fine. Other Intel CPUs and Network Adapters like this work, so this one should too."
VMware also has nothing to lose by putting it in their HCL. If it doesn't work, they will just say it's a HW or driver issue and tell you to call Cisco. They will then quite conveniently point you to their KB article where they say that you are supposed to follow Cisco's HCL and then tell you are technically not supported as it is missing in our Interop.
Cisco puts all items in the interop through rigorous tested to confirm it functions as expected. If it fails, we either fix the underlying issue, determine that something isn't supported, or document in the footnotes of the HCL any exceptions. Only once this is documented do we add it to our HCL.
Cisco has little to no control over what another company chooses to put on their websites. We can ask that they take it down, but ultimately since they tell you to ignore what they say and do what we say, there is no compelling reason for them to comply.
To compound matters, Cisco cannot do testing until the new version of VMware becomes publicly available. So as soon as a new version comes to market for VMware, we put testing in motion. This takes time and we prioritize various products/configurations to get things covered as quickly as possible.
This is also why it takes time to create a Cisco Custom ISO for a given version. We can't even start until it is officially released and then we have to complete testing on some products to make sure that the drivers we are injecting into the ISO aren't affected by some underlying OS change in the new version. This simply takes time.
Cisco does't feel that we do a service to our customer's by blindly putting things on the HCL that haven't been tested. What if you upgraded thousands of nodes just to run into some issue on a product that was never tested? Again, we are putting your business first by doing thorough testing first.
VMware is a fantastic product, but this is common with every new release. We can't control what they do/do not change in their OS. We have to start from scratch with testing with every new release that comes out.
I hope this provides some insight into why this process takes time.
1) My meaning of support is similar to your statement, with the expectation of continue to support newer OS except in the last year. I wouldn't expect Cisco to add a new OS on the last year a product will be supported.
2) If there are plans to test and support my setup, that is great. Just a phone call and say that will be fine. This was done in the past when I had conversations in past about vVols support. About my account team and VAR, my VAR pasted away in the past year and was basically the account team. The account team has been very hands off the past few years and he has recently left. We have someone who is filling in temporary till the position is filled in again.
3) I heard from VMWare that they get the Cisco HCL from Cisco. But I don't really know.
What I really don't get is that is a question of CPU support from v1 to v2(which is on Cisco's HCL). But if it is being tested, that's great.
In 6.7 a number CPUs got desupported per release notes
•AMD Opteron 13xx Series
•AMD Opteron 23xx Series
•AMD Opteron 24xx Series
•AMD Opteron 41xx Series
•AMD Opteron 61xx Series
•AMD Opteron 83xx Series
•AMD Opteron 84xx Series
•Intel Core i7-620LE Processor
•Intel i3/i5 Clarkdale Series
•Intel Xeon 31xx Series
•Intel Xeon 33xx Series
•Intel Xeon 34xx Clarkdale Series
•Intel Xeon 34xx Lynnfield Series
•Intel Xeon 35xx Series
•Intel Xeon 36xx Series
•Intel Xeon 52xx Series
•Intel Xeon 54xx Series
•Intel Xeon 55xx Series
•Intel Xeon 56xx Series
•Intel Xeon 65xx Series
•Intel Xeon 74xx Series
•Intel Xeon 75xx Series
My use case. We have multiple vsphere clusters running on b200m3. We just purchased some new servers running VSAN for DR. Would like to run the new servers to run 6.7(with VSAN 6.7), but I need production servers to run 6.7 so vsphere replication will work from Production to DR.
Features to want to use
Want to used the improved vCSA, vsphere quick boot feature in esxi.
I just want to know how far will my setup will continue to get new released supported in VMWare. Will it stop at ESXi 6.5U1?, Update 2 just came out, will it be supported on 6.5 U3. etc? It won't be cheap to replace these servers and we need notice so we can try to get this budgeted and be somewhat current on VMWare. I will follow up and see what our account rep found out.
I know everyone that has responded is trying to be helpful and may not have all the answers I am looking for. We've been UCS since 1.X code days and it has been a solid product. The servers always stayed up.
I wanted to follow up on this thread. 6.7 is now supported for B200M3 according to Cisco's HCL page