VCF vs Proxmox 9.2
czego brakuje i jak to nadrobić

Stos SDDC kontra modułowy Proxmox

VCF łączy kilka produktów w jeden zarządzany pakiet. Proxmox dostarcza równoważne funkcje, ale jako modułowy, otwarty zestaw klocków. Mapowanie warstw:

Czego brak twardo: zero-downtime FT i bezagentowe AV

Poniżej trzy funkcje VCF, których w Proxmox VE 9.2 nie odtworzysz 1:1 — niezależnie od tego, ile narzędzi dołożysz. Każda z nich ma jednak sprawdzony substytut; reszta typowych luk wdrożeniowych to sprawy organizacyjne lub limitowe, zebrane w sekcji 06.

Czego brak twardo: zero-downtime FT

To najczęściej wskazywana realna luka. VMware Fault Tolerance (FT) trzyma zapasową kopię maszyny na drugim hoście i przy awarii wznawia ją od ostatniego checkpointu — bez utraty danych. To nie jest dawny tryb krok-w-krok. W wymaganiach VCF bywa to zapisane jako ochrona VM do 2 vCPU z RTO=0 i RPO=0: ciągła praca wybranej maszyny, nie restart. Proxmox nie ma odpowiednika FT; ma HA, czyli automatyczny restart maszyny na innym węźle (przestój liczony w sekundach–minutach).

Jak to nadrobić w Proxmox:

• Redundancja w aplikacji — klaster aplikacyjny, replikacja bazy (Patroni/Galera), para load-balancerów. To i tak właściwy wzorzec HA dla usług krytycznych.
• HA + szybki restart — dla większości obciążeń restart w kilkadziesiąt sekund jest w pełni akceptowalny.

Czego brak twardo: bezagentowe AV z hypervisora

VMware potrafi skanować maszyny bez agenta w środku — Guest Introspection przez vSphere API for Endpoint Protection (NSX / VCF Security) wchodzi w pamięć i system plików gościa z warstwy hypervisora. Proxmox takiego mechanizmu nie ma: jego firewall to filtr pakietów na poziomie mostka, a nie inspekcja procesu czy pliku wewnątrz VM. Nie ma też odpowiednika „wyłącznika agenta” przy klonowaniu złotej maszyny.

Jak to nadrobić w Proxmox:

• Agent EDR/AV w gościu — Defender for Endpoint, CrowdStrike, Wazuh/Selinux w Linuxie; standardowy wzorzec poza ekosystemem VMware.
• Inspekcja na brzegu — NGFW z IPS/AV (OPNsense, pfSense) przed newralgicznymi segmentami, ewentualnie sandbox do analizy próbek.
• Skanowanie obrazów i backupów — Trivy/ClamAV w pipeline oraz po stronie PBS; wykrywanie zagrożeń w repozytorium zamiast w pracującej VM.

Czego brak twardo: offload sieci na DPU/SmartNIC

vSphere + NSX potrafią zrzucić tunelowanie VXLAN, reguły rozproszonego firewalla i część dataplane na kartę DPU/SmartNIC. Strona porównania Proxmox VE opisuje produkt jako w 100% programowy — offloadu na DPU nie ma, więc koszt sieciowej wirtualizacji płacisz cyklem CPU hosta.

Jak to nadrobić w Proxmox:

• Tani offload sprzętowy — hardware LRO/TSO/RSS na kartach Intel/Mellanox oraz SR-IOV passthrough, gdy gość potrzebuje pełnej przepustowości.
• Mniej tuneli — tam gdzie to możliwe VLAN zamiast VXLAN/EVPN; płaska sieć fizyczna z LAG-iem zwykle wystarczy.
• Czego nie uzyskasz — rozproszonego firewalla z akceleracją na DPU; przy dużej liczbie tuneli i reguł L7 trzeba to projektować po stronie NGFW.

Sieć i mikrosegmentacja bez NSX

NSX to zaawansowana platforma sieciowa: rozproszony firewall (mikrosegmentacja na poziomie karty VM), reguły L7, bramy NAT/VPN/Load Balancer, federacja między ośrodkami. Proxmox pokrywa fundament — EVPN/VXLAN (sieci nakładkowe, multi-tenant) oraz wbudowany firewall (domyślnie iptables, backend nftables jako wersja zapoznawcza; reguły per-VM i grupy) — ale nie ma gotowego rozproszonego firewalla L7 ani bram usługowych „z pudełka”. Bezagentowe skanowanie antywirusowe i offload na DPU omówiłem osobno w sekcji 02 („Czego brak twardo”). SDN centralnie definiuje strefy i VNety na wielu hostach, ale dokumentacja nie opisuje Network I/O Control ani eksportu NetFlow/IPFIX z warstwy wirtualnej.

Jak to nadrobić w Proxmox:

• Mikrosegmentacja — firewall Proxmox (per-VM/CT) + grupy bezpieczeństwa i strefy VLAN/VXLAN; reguły jadą z konfiguracją maszyny.
• Bramy L7 / NAT / VPN / LB — wirtualny NGFW (OPNsense, pfSense) albo HAProxy/NGINX i WireGuard/IPsec jako dedykowane maszyny brzegowe.

Operacje i automatyzacja z open-source

Narzędzia VCF 9 — VCF Operations, VCF Automation, VCF Operations for logs i VCF Operations for networks (dawniej Aria / vRealize: vROps, vRA, Log Insight, Network Insight) — dają monitoring, planowanie pojemności, self-service i analitykę logów w jednym. Proxmox nie ma jednego takiego pakietu — składasz go z dojrzałych, otwartych narzędzi:

• Monitoring i pojemność — wbudowany serwer metryk zewnętrznych wysyła statystyki hostów, gości i storage do Graphite, InfluxDB lub OpenTelemetry (np. InfluxDB + Grafana); dla Prometheus + Grafana potrzebny jest dodatkowo eksporter prometheus-pve-exporter (gotowe dashboardy dla Proxmox/Ceph).
• Pobór energii — pomiaru hosta ani poszczególnych VM Proxmox nie udostępnia.
• Logi — Loki lub stos ELK/OpenSearch do centralnej analizy.
• Automatyzacja i self-service — Terraform (provider społeczności, na przykład bpg/proxmox) i Ansible na bazie pełnego REST API Proxmoxa.

SDDC Manager i certyfikacje ISV

• Lifecycle stacku — od VCF 9 łatanie jest w VCF Operations, a bring-up w VCF Installer (walidowane obrazy). SDDC Manager zostaje w stosie, ale bez API lifecycle. W Proxmox aktualizujesz prościej (apt i Ansible; skrypt pve8to9 tylko przy skoku 8→9) — mniej „magii”, ale i dużo mniej ruchomych części do utrzymania. Quick Boot (pominięcie inicjalizacji serwera po aktualizacji) nie ma odpowiednika; po aktualizacji jądra i mikrokodu wiki Firmware Updates wymaga rebootu hosta.
• Firmware producentów — vSphere Lifecycle Manager pakuje firmware dysków, kontrolerów i kart oraz weryfikuje rekomendowane sterowniki dla producentów serwerów. Konsola Proxmox tego nie robi: wiki Firmware Updates odsyła do narzędzi dostawcy (Dell Lifecycle Manager, HPE Service Pack) oraz pakietu pve-firmware (firmware runtime kart, nie BIOS macierzy).
• KMS — Proxmox nie ma wbudowanego Key Management Server. Szyfrowanie kopii PBS trzyma klucz AES lokalnie w klastrze; TPM w qm to emulowany stan dla gościa, nie KMS.
• Certyfikacje ISV — część dostawców (SAP, Oracle) certyfikuje produkty głównie na VMware. W Proxmox bywa to kwestia negocjacji warunków wsparcia; KVM jest powszechnie wspierany, ale macierz certyfikacji jest węższa.
• Self-service / multi-tenant cloud — odpowiednik VCF Automation (który przejmuje też obsługę wielu najemców z Cloud Directora) budujesz w Proxmox z pul zasobów, RBAC i API (ewentualnie portal własny lub firm trzecich).

Czego VCF wymaga, a Proxmox nie deklaruje

Poniżej funkcje typowe dla VCF/vSphere, zestawione z dokumentacją Proxmox VE. Proxmox publikuje maksima hosta (8192 logicznych CPU, 128 TiB RAM, 8 socketów) — to nie są te same liczby co vSphere. Od 9.x jest Dynamic Load Balancer, więc luka DRS nie obowiązuje. Dokumentacja qm nie podaje osobnego limitu vCPU per VM poza blokadą startu z liczbą vCPU większą niż fizycznie na hoście. Tematy podzieliłem na cztery bloki — każdy ma własny podrozdział.

Czego VCF wymaga, a Proxmox nie deklaruje: limity hosta i VM

To różnice w dokumentowanych maximach, nie w realnej pojemności: Proxmox nie gwarantuje liczb podawanych w wymaganiach, ale jego własne limity są wyższe na RAM i wątki, niższe na liczbę socketów.

Czego VCF wymaga, a Proxmox nie deklaruje: API i integracje partnerskie

W praktyce: narzędzia, które opisano przez VAAI/VASA lub „Backup from Storage Snapshots”, trzeba dobrać tak, by działały na poziomie Proxmox/Ceph (PBS, hook scripts, snapshoty RBD), a nie przez API VMware.

Czego VCF wymaga, a Proxmox nie deklaruje: sieć i telemetria

Telemetrię ruchu i zużycia zwykle przenosi się na warstwę fizyczną (sFlow/NetFlow na switchu, IPMI/metrics exporter na zasilaczu hosta) — Proxmox tego nie udostępnia z poziomu hypervisora.

Czego VCF wymaga, a Proxmox nie deklaruje: bezpieczeństwo i lifecycle

Trzy pierwsze pozycje to luki twarde omówione w sekcji 02; pozostałe to braki organizacyjne, które domykają narzędzia dostawcy serwera, Ansible i zewnętrzny KMS/HSM.

SDN, firewall i Ceph są w tej samej subskrypcji Proxmox VE, ale to nie jest rozproszony firewall z mikrosegmentacją w rozumieniu NSX ani lifecycle całego stosu w jednej konsoli klasy SDDC Manager — to już w sekcjach 03 i 05.

Kiedy VCF, a kiedy Proxmox 9.2

Po stronie 9.2 zniknęła większość historycznych argumentów „za VMware” (DRS, snapshoty SAN jako łańcuch wolumenów — nadal wersja zapoznawcza, reguły HA, SDN). Zostają nieliczne, konkretne przypadki:

• Wybierz VCF, gdy twardo wymagasz: Fault Tolerance zero-downtime, głębokiej mikrosegmentacji NSX z regułami L7, vSphere Lifecycle Manager do firmware serwerów, VAAI/VASA, bezagentowego AV z hypervisora, wbudowanego KMS, NIOC/NetFlow, offloadu na DPU, certyfikowanego stacku ISV albo gotowego self-service cloud (VCF Automation).
• Wybierz Proxmox VE 9.2 w pozostałych ~95% przypadków: brak opłat licencyjnych i lock-in, pełna kontrola, a wymienione luki nadrabiasz sprawdzonymi wzorcami (redundancja aplikacyjna, NGFW, Prometheus/Grafana, Terraform/Ansible).