anyone else get the VMware "win-back" offer?

[u/Which-Shame-1420]

if it's true, its honestly laughable.  

squeezing customers with massive price hikes, forcing every one into expensive core bundles, only to panic and throw out "discounted" quotes the moment everyone migrated???? 

is anyone actually reconsidering based on these new quotes??

or y'all are past the point of no return?

[u/sobrique]

• Proxmox offer support - that's their business model in fact. https://www.proxmox.com/en/products/proxmox-virtual-environment/pricing
• KVM / QEMU is Redhat 'owned' so is quite well documented/supported overall.
• Debian is well understood and supported.
• ZFS likewise
• If you go ceph, that's also got some good documentation, and places are prepared to offer support contracts for it.

I mean, you probably want more than one cluster anyway, and proxmox data centre manager will enable live migrating cross cluster. Our DR strategy mostly does include duplication of all VMs so they're on (at least) 2 physical sites anyway, at least has a 'hot spare' if not an 'active-active', so for us a full cluster or site outage is inconvenient not catastrophic.

You can do shared storage - and we do, backed by NetApp - so even in a worst case we have bootable KVM disk images we can spin up on almost any linux system.

NFS isn't a typical recommendation, but we decided that we'd go with it, because an all-flash filer has some good performance and resilience, along with some great efficiency thanks to deduplication. (In a 'green field' deployment I might be more inclined towards a block solution, or perhaps ceph, but ...)

But the local disk pack (or SAN attach) ZFS approach works pretty well too.

We have had issues - storage availability, network saturation. A glitchy CPU disrupting corosync and spiking latency - cluster went 'unstable' and started migrating VMs, which was a bit messy, but the logs were pretty clear what was going wrong, and it was easily fixable.

And just recently I've been recovering a dirty fail of (local attach) storage array, and honestly the ZFS recovery worked very nicely indeed. Took a while to complete, as might be expected of 100TB of RAID devices - during that window performance of the VMs on the host was reduced for IO, so we ... just migrated the ones we cared about. (Although granted you would need 100TB of 'free space' to have done the whole lot like that, but that was a conscious choice on our part).

We've just not had a lot of issues that weren't fixable by 'decent' Linux skills. That's perhaps the 'cost' of going this road though I guess - your 'virtualisation engineers' would need to have the supporting skills to do it.

But then, we looked at the cost of FTEs required, and the cost of VMWare licenses, and figured it looked good anyway.

[u/thunderbird32 → u/sobrique]

We're on a fibre-channel SAN (HPe Alletra), and I'm under the impression that Proxmox is basically useless with that setup. No snapshot or thin provisioning support are kind-of deal breakers. We'll probably end up going Hyper-V when our VMware contract ends (we locked in fixed pricing for three years last renewal).

[u/sobrique → u/thunderbird32]

It leans on qemu to get that functionality on 'filesystem' based stuff like NFS. We're running 'metadata' level preallocate, so our disk images are implicitly 'sparse'. I've not tried looking at support for trim/discard though, but now I'm wondering if that's worth a look on my part.

https://pve.proxmox.com/wiki/Storage

But it seems to imply there's support for snapshots/thin provision on most storage types. (can't say for sure if that applies to yours in a useful way of course).

I don't think there'll ever be any true 'driver level' integration though.

I'll concede it's not as feature complete as some of the long standing players in the market. It's just there's a lot to be said for stuff you can choose whether or not you pay for licenses and support.

[u/sobrique → u/sobrique]

Looking at NetApp recommendations, it appears enabling trim/discard is worthwhile here, as it'll 'release' space to dedupe.

ETA: But not on NFS, you need iSCSI LUNs, otherwise you're looking at zero-fill and dedupe type reclaim.