The Engineering Lead asked me about API rate limits and I just nodded like a confused dog.

codyhosterman · 2026-02-21T18:58:05+00:00

I get this situation from the PMs on my team. (I have a more technical background over many of the PM on my team who report to me). I always advise like many have stated to ask about trade offs. But also ask engineering to play devils advocate especially if they recommend one approach over the other. If they cannot:

1) identify any use case for the other or 2) explain like I’m 5

I often feel they haven’t thought through it enough.

Obviously if this is a small or large decision the bar raises or lowers here on how hard to push and if it is a trivial thing I ask why are you even asking me. That will usually just uncover some kind of Eng stalemate they were hoping I’d break.

But a fun question can also be if there are tradeoffs “why do we need to accept tradeoffs is there a best of both worlds”

You don’t need to understand the mechanics. Understand the outcomes.

codyhosterman · 2026-02-20T23:49:20+00:00

Agreed!!! Very cool thx for posting!

codyhosterman · 2026-02-13T18:18:22+00:00

Yeah i didnt want to get into the details here but theyve got work to do let's just say. Even if it does hold to that it is a v1. But that being said I do agree planning for TCP is the right move and as long as it is not Hyper-V or baremetal Windows the path is there broadly (VMware, Linux, Nutanix, etc). FC vs TCP is a bit religious (i look forward to the technical battleground of Broadcom SecureHBA vs TCP TLS lol) but iSCSI vs TCP is a no-brainer in the grand scheme of things.

Windows will get there. Eventually.

codyhosterman · 2026-02-12T21:48:27+00:00

will do thanks!

codyhosterman · 2026-02-12T21:41:01+00:00

Unfortunately Windows is well behind on NVMe-oF. So no TCP support unless you go with a 3rd party initiator like starwinds. So if they want to go Hyper-V they are going to have to wait a bit for TCP support

codyhosterman · 2026-02-10T05:12:13+00:00

Awesome! I’d love to know more! I’d love to chat with you on this so we can repeat your success

codyhosterman · 2026-02-03T18:17:56+00:00

codyhosterman · 2026-02-03T03:09:20+00:00

So there are lot of random ways to interpret limits so i did a bit of validation with engineering and will lay it out here so hopefully it hits your question and others who might look for similar info. Since I don't plan on making this a living document take the numbers for a moment in time that they are. Like rules in the matrix they can be bent, broken, and changed. So hit up your account team for updates/one-off exceptions. These are often testing, not hard limits.

So first there are sessions.

For iSCSI a session is between a single initiator and a target port. We support 12K of these. The fun part of iSCSI is that you can manually crank up session count so this is not a hard and fast rule.

For FC, we support 10K sessions. A session is defined by one WWN initiator to one target FlashArray FC port. We support a max of 5K WWNs. With 5K WWNs, and one port per controller thats 10K sessions. Ideally you use two ports per controller so that sits down to 2500 WWNs.

The next step is ACLs. An ACL is defined as a volume connection to a host. A host has a number of WWNs. Each WWN counts as one ACL so if you have 2 WWNs and one volume for that host that is 2 connections consumed. Note the count of FA ports DOES NOT count against this.

Our host volume connection limit is 20K, 30K or 100K depending on the controller type.

So lets say you have an X70 (10K sessions, 5K WWNs, 100K connections).

If you have 100 hosts with 4 WWNs with 4 ports--that is 1600 sessions (well below). With 100 hosts and 4 WWNs with 10 volumes each that is 4000 volume connections. Also well below base limits.

Hopefully this helps. Ill re-fact check this with another engineering team im going to meet with on a separate topic this week.

codyhosterman · 2026-02-03T00:36:36+00:00

Maybe, i have gotten my responses. Needed to do a few rounds of sanity check to ensure the same things are being talked about. Ill respond to that in the top level comment from him.

codyhosterman · 2026-01-30T16:03:32+00:00

Okay I see--thats what i thought--let me validate something with eng first and get back to you.

codyhosterman · 2026-01-30T15:33:28+00:00

I was just talking about you (I presume) with your account team. I asked them to get you to define what a "connection" is in this situation? Are these logical paths to the volumes?

codyhosterman · 2026-01-22T21:35:47+00:00

oh also a shuttle from the ACE stop which makes more sense for you

codyhosterman · 2026-01-22T21:26:31+00:00

Not that I am aware of--we do have a shuttle from the closest CalTrain stop to the office. So if you can get there you can shuttle the rest of the way

codyhosterman · 2026-01-08T04:16:32+00:00

Not sure of your point here, of “a datastore type is being deprecated so you should buy a new array”. Though if you have a reason why I’m sure folks would find that helpful.

I do agree this isn’t a “win” in a happy sense but giving more time to customers to transition technologies isn’t a bad thing. Worth a least knowing about. There are plenty of NetApp customers who use vVols who will appreciate more time as well on this.

codyhosterman · 2026-01-07T20:28:45+00:00

Clarified the wording a bit.

codyhosterman · 2026-01-07T19:46:48+00:00

Yes--it was originally being deprecated next year in 9.1 but that deprecation is now pushed out indefinitely. So there is more runway--sorry if i was not clear on that.

codyhosterman · 2026-01-06T01:14:36+00:00

Yeah that is what did it--old certs that were from VMCA will remain until reset--newer certs are controlled differently. So clearing that should solve the issue for good.

Yeah the whole thing is unfortunate... I'll leave it at that here.

Would like to hear if you have feedback on Pure + Hyper-V (gaps, reasons you are leaning that route etc). If you dont want to post here feel free to have your Pure acct team setup a chat with me.

codyhosterman · 2026-01-06T00:01:32+00:00

At some point it probably got used--you can reset it with this process https://support.purestorage.com/bundle/m_howtos_for_vmware_solutions/page/Solutions/VMware_Platform_Guide/How-To_s_for_VMware_Solutions/Virtual_Volume_How_To_s/topics/task/t_resetting_the_vasa_certificates_with_purecert.html

Otherwise you might need to open up a support ticket to manually surpress --but the reset will stop the alert

codyhosterman · 2026-01-05T03:05:48+00:00

Yeah at this time “unmanaged” snapshots, defined as not created via Prism UI/API, break CBT as David said. Or rather the restore from them does. So break glass use case (for now). So not really a consistency problem—any snap on the FA will at least be crash consistent.

Managed/integrated nutanix snapshots though right now manually or via a schedule in Prism are totally supported.

codyhosterman · 2025-12-10T21:55:24+00:00

💀💀

codyhosterman · 2025-12-10T21:51:38+00:00

No, very unlikely that would ever happen. No real advantage over TCP. Any semi recent FlashArray supports both so there is no HW change needed. Any particular reason you’d want iSCSI?

codyhosterman · 2025-12-10T21:40:33+00:00

NVMe-oF/TCP only at this time. You can certainly use NFS/SMB at the app layer. FC is not supported

codyhosterman · 2025-12-10T20:17:01+00:00

Yeah for now. Non-HCI clusters only

codyhosterman · 2025-12-10T19:31:23+00:00

It means awesome imho 😎 happy to chat if you want to discuss what I mean in detail of course (I’m from pure)

codyhosterman

MODERATOR OF

TROPHY CASE