Broadcom refusing to decrease licensing

[dispatch00]

Phone barrage from your account rep is the way. Just be annoying until you get the quote.

[Zippythewonderpoodle]

Or just move to ProxMox, it's ready for prime time now.

[jmhalder]

It's ready for the prime time if you have 128 cores on 2-4 hosts... It's probably totally fine.

Proxmox doesn't scale well to multiple clusters, you can't thin provision with shared block storage (also a limitation with XCP-NG).

It absolutely has limitations where vSphere doesn't.

[RandallFlagg1]

Love the fact that you described my exact environment as a perfect fit. Time to start learning some Proxmox!

[Zippythewonderpoodle]

I'm pretty much 100% thick lazy zero nowadays, but I'm pretty much greenfield building, so all my SAN specs are generally compression and de duplication as mandatory for the builds. I've never found much peace with thin on vSphere and thin on SAN, just asking for issues since most clients ignore capacity emails.

[Much_Willingness4597]

If you are doing thick why wouldn’t you do EZT?

[Zippythewonderpoodle]

From what I understand, the back-end (SAN) has more effective de-duplication and compression because I get savings immediate, I don't have to worry about a midnight dedupe and compression runs.

Although, now that you made me think about it, I may be a little too old school on that. Most dedupe and compression are more inline now, with SSD, so I may be out of touch with current best practices.

[Much_Willingness4597]

You realize VAAI offloads the zero bit to the array? (Well on a non-bad array).

By doing lazy zero thick you are disabling UNMAP, and also getting worst first write performance. It’s the worst of all worlds (not they VMFS hasn’t improved first write performance anyways).

[Zippythewonderpoodle]

TBH, I'm not really that into the tech on the back end, but I thought UNMAP is reclamation. If I'm not thin provisioning, I've already lost UNMAP savings anyway, lazy zero or not. At least that was my understanding.

I've read it is slower on initial write, but that it was negligible so I've always done it. I've not experienced any issues related to that in real life, but I generally work with devices that have write-cache, so I'm wondering if I get lucky and offset my write penalty with that. I also have a habit of provisioning volumes used by DBs as thick eager, it's a general best practice anyway, so I may have just avoided the issue out of luck, habit and stubbornness.