VMware to Proxmox VE Migration — Stretched Cluster D1/D2/D3

OPS

TECHNICAL GUIDE · INFRASTRUCTURE MIGRATION · JUNE 2026

◆◆◆

VMWARE TO
PROXMOX VE MIGRATION
Stretched Cluster D1 · D2 · Witness D3
Generic study · Full stack

◆

From VMware/Broadcom lock-in analysis
to a 5-phase operational migration plan

◆◆◆

6VMware lock-in layers

3Datacenters D1/D2/D3

5Migration phases

7Stack layers migrated

◆

TABLE OF CONTENTS — 10 PAGES

◆ Page 2 · VMware/Broadcom lock-in anatomy

◆ Page 3 · Current VMware reference architecture

◆ Page 4 · Target Proxmox architecture

◆ Page 5 · Stretched cluster specific risks

◆ Page 6 · 5-phase migration plan

◆ Page 7 · Reference open-source stack

◆ Page 8 · Change management & skills

◆ Page 9 · Decision grid & approximate ROI

◆ Page 10 · Tools & resources

◆◆◆

This document is a generic technical study. Configurations mentioned are illustrative.
It does not constitute individualised engineering advice. Public document · CC BY-NC-SA 4.0

◆

Amine RAITI · Infrastructure Architect & SRE
Public document · CC BY-NC-SA 4.0 · AI Powered by Amine

OPS

PAGE 2 · VMWARE/BROADCOM LOCK-IN ANATOMY

VMware LOCK-IN — 6 LAYERS · BROADCOM CONTEXT

◆

◆ BROADCOM POST-NOVEMBER 2023 CONTEXTDOCUMENTED PRICING RUPTURE

Broadcom's acquisition of VMware in November 2023 immediately restructured licensing: perpetual licences discontinued · forced migration to annual subscriptions · documented price increases of ×3 to ×12 depending on configuration · Standard and Essentials editions eliminated in favour of imposed bundles. This is Layer 2 (pricing) of vendor lock-in applied to on-premise infrastructure — the same mechanism as cloud hyperscaler egress fees. The difference: the increase is immediate and without contractual alternative.

Layer

VMware/Broadcom mechanism

Intensity

Exit nature

1 · Contractual

Perpetual licences discontinued · non-cancellable subscriptions · support conditioned on active subscription · unilaterally modifiable Product Terms

●●●●

Legal · negotiation or migration

2 · Pricing

×3 to ×12 increase post-Broadcom · imposed bundles · double-run cost during migration · no alternative without full migration

●●●●

Financial · ROI <24 months in most cases

3 · Technical

VMDK format (convertible) · proprietary vSphere APIs · NSX-T network overlay · vSAN storage · Tanzu K8s · SPBM policies

●●●

Moderate technical · conversion tools available

4 · Skills

VCP/VCAP/VCDX certifications ubiquitous · attachment bias in ops teams · passive resistance from middle management

●●●

Training · reskilling plan

5 · Demand

vCenter as cognitive reference for infra teams · "we want vSphere" expressed by business units before any alternative evaluation

●●

Change management · functional reformulation

6 · Cognitive

Infra KPIs defined in vCenter/vRealize · Aria dashboards as performance benchmark · impossible to compare outside this benchmark

●●●

Irreversible without migration · rebuild KPIs

⚠ STRETCHED CLUSTER SPECIFICS — 3 ADDITIONAL COMPLEXITY DIMENSIONS

The D1/D2/D3 configuration adds three critical constraints absent from standard migrations: (1) vSAN inter-site synchronisation with tolerance for complete site loss — the D3 witness stores no data but arbitrates quorum; (2) NSX T0/T1 Gateway in active/standby mode across datacenters with North-South flow management between sites; (3) split-brain risk if the D1↔D2 link is cut — without D3 arbitration, both sites can diverge. These three dimensions impose a strict migration sequence: network before storage before compute.

OPS

PAGE 3 · CURRENT VMware REFERENCE ARCHITECTURE

VMware STRETCHED CLUSTER ARCHITECTURE — D1 · D2 · D3

◆

D1 (Primary Site) D2 (Secondary Site) D3 (Witness) ├── ESXi Hosts (N) ├── ESXi Hosts (N) └── VMware Witness Appliance ├── vSAN datastore (preferred) ├── vSAN datastore (secondary) (vote only — zero data) ├── NSX Edge T0/T1 (active) ├── NSX Edge T0/T1 (standby) ├── vCenter Server (active) └── vCenter Server (passive HA) └── DRS + HA enabled └────────── vSAN Stretched Cluster ──────────┘ Synchronous replication D1 ↔ D2 · FTT=1 PFTT=1 Max recommended latency: 5ms RTT D1↔D2 · 200ms D1/D2↔D3

◆ STORAGE LAYER — vSAN STRETCHED

vSAN Stretched Cluster with FTT=1 and PFTT=1: tolerates complete loss of one site (D1 or D2) without data loss. The Witness Appliance on D3 carries metadata components (witness components) to arbitrate quorum without storing VM data. SPBM storage policy: vSAN objects are distributed between D1 and D2 according to site-aware placement rules. On D1 loss, all VMs fail over to D2 via vSphere HA — the Witness D3 maintains quorum.

◆ NETWORK LAYER — NSX-T

NSX-T Tier-0 Gateway in active/standby inter-site mode: active T0 on D1 handles North-South routing · standby T0 on D2 takes over on D1 loss. Tier-1 Gateways per tenant/segment. GENEVE overlay on physical transport. Distributed Firewall (DFW) applied per VM vNIC — the firewall follows the VM regardless of physical location. VTEP on each ESXi host.

◆ ORCHESTRATION LAYER — vCENTER

vCenter Server in HA or Enhanced Linked Mode. DRS: workload balancing across hosts with site-aware affinity rules to avoid suboptimal inter-site placement. vSphere HA: automatic VM restart on surviving site on site loss. Fault Domain management: D1 = Preferred · D2 = Secondary.

◆ K8s LAYER — TANZU

VMware Tanzu Kubernetes Grid (TKG) or vSphere with Tanzu: K8s clusters supervised by vCenter · storage via vSAN CSI driver · networking via NSX-T NCP (NSX Container Plugin). Tanzu workloads co-located with VMs on the same vSAN/NSX fabric — Tanzu → K3s/K8s vanilla migration requires Velero for workload backup/restore.

◆ PROTECTION LAYER

Veeam Backup & Replication or VMware SRM for recovery plans. RPO/RTO defined by criticality tier: Tier 1 (RPO <15min · RTO <1h) · Tier 2 (RPO <1h · RTO <4h) · Tier 3 (RPO <24h · RTO <24h).

OPS

PAGE 4 · TARGET PROXMOX VE ARCHITECTURE — D1 · D2 · D3

PROXMOX STRETCHED ARCHITECTURE — CEPH · OVN · COROSYNC

◆

D1 (Primary Site) D2 (Secondary Site) D3 (Arbiter / Tiebreaker) ├── Proxmox VE Hosts (N) ├── Proxmox VE Hosts (N) └── Corosync QDevice (corosync-qnetd) ├── Ceph OSD (rack: dc1) ├── Ceph OSD (rack: dc2) Ceph MON tiebreaker ├── Ceph MON / MGR ├── Ceph MON / MGR (vote only — zero OSD) ├── OVN Chassis (active) ├── OVN Chassis (active) └── Proxmox cluster node └── Proxmox cluster node └──────── Ceph Stretched Cluster ───────────┘ Synchronous replication D1 ↔ D2 · stretch_mode Max acceptable latency: 10ms RTT D1↔D2 · 30ms D1/D2↔D3

◆ STORAGE LAYER — CEPH STRETCHED

Ceph in stretched cluster mode with custom CRUSH map: bucket type datacenter containing D1 and D2 racks. CRUSH rule: stretch_mode true · mon stretch_cluster · min_size=2 · size=4 (2 copies D1 + 2 copies D2). MON tiebreaker on D3 arbitrates Ceph quorum without OSD. RBD (RADOS Block Device) as VM storage backend — direct interface with Proxmox VE via Ceph pool.

◆ NETWORK LAYER — OVN + OVS

OVN (Open Virtual Network) with Open vSwitch: full functional replacement of NSX-T. Distributed OVN logical router: T0/T1 equivalent. GENEVE overlay (same protocol as NSX-T — same encapsulation). OVN ACLs: Distributed Firewall equivalent. BGP EVPN with FRRouting for inter-datacenter routing and D1↔D2 flow symmetry. OVS VTEP on each Proxmox host.

◆ ORCHESTRATION LAYER — PROXMOX CLUSTER

Proxmox VE cluster via Corosync + QDevice (corosync-qnetd) on D3. HA Groups per datacenter: restricted=1 for Tier 1 VMs (stay on preferred site) · restricted=0 for Tier 2/3 (auto-migrate to surviving site). Fence devices per site: IPMI/iDRAC for physical isolation on split. Live migration between D1 and D2 via KVM live migration (vMotion equivalent).

◆ K8s LAYER — K3s / K8s VANILLA

K3s or vanilla Kubernetes on Proxmox VMs · Longhorn or Ceph RBD CSI driver for persistent storage · Calico or Cilium for pod networking · Velero for workload backup/restore (migration from Tanzu). K3s recommended for small clusters (<20 nodes) · vanilla K8s for more complex environments.

◆ PROTECTION LAYER

Proxmox Backup Server (PBS): incremental VM backup with deduplication · configurable retention · client-side encryption. As complement or replacement: Veeam Community Edition (free up to 10 workloads) or existing Veeam licence during transition if contractually permitted.

vSAN function

Ceph equivalent

NSX-T function

OVN equivalent

Fault domain (site)

CRUSH bucket datacenter

T0/T1 Gateway

OVN Logical Router

Witness Appliance

MON tiebreaker D3

Distributed Firewall

OVN ACLs

PFTT=1 (site fault)

stretch_mode min_size=2

GENEVE overlay

GENEVE (same protocol)

SPBM policies

Ceph pools + RBD

NSX-T NCP (Tanzu)

Calico/Cilium CNI

vSAN Encryption

Ceph at-rest encryption

VTEP (per ESXi host)

VTEP OVS (per PVE host)

OPS

PAGE 5 · STRETCHED CLUSTER SPECIFIC RISKS D1/D2/D3

CRITICAL RISKS — SPLIT-BRAIN · LATENCY · SEQUENCING

◆

◆ RISK 1 — SPLIT-BRAIN: THE PRIMARY STRETCHED CLUSTER RISKCRITICAL

If the D1↔D2 network link is interrupted, both sites may continue operating independently with diverging data. Without external arbitration (D3), both sites consider themselves the "live" site and continue accepting writes — producing irrecoverable data divergence.

vSAN STRETCHED
D3 Witness arbitrates via vSAN quorum. Site without quorum goes read-only. Automatic recovery on D1↔D2 reconnection.

CEPH STRETCHED
D3 MON tiebreaker arbitrates Ceph quorum. Site without quorum stops accepting writes (degraded PGs). Automatic recovery on reconnection.

COROSYNC/HA
D3 QDevice arbitrates Proxmox quorum. STONITH fencing per site. HA policy: fence minority site before VM relocation.

Critical prerequisite: the D1/D2↔D3 link must be independent of the D1↔D2 link. If D3 is on the same network path as D1↔D2, the tiebreaker cannot arbitrate a failure on that link.

◆ RISK 2 — INTER-SITE LATENCY: COMPARATIVE CONSTRAINTSHIGH

Technology

Max recommended latency

Max acceptable latency

Impact if exceeded

vSAN Stretched D1↔D2

5ms RTT

10ms RTT

Degraded performance · SCSI timeouts

Ceph Stretched D1↔D2

10ms RTT

20ms RTT

OSD heartbeat warnings · I/O performance

Corosync/QDevice D↔D3

10ms RTT

30ms RTT

Unstable quorum · HA false positives

vMotion / Live migration

150ms RTT

250ms RTT

Migration duration increases

vSAN D1/D2 ↔ D3 Witness

200ms RTT

500ms RTT

Unstable vSAN quorum

Key point: Ceph stretched tolerates 10ms D1↔D2 latency vs 5ms for vSAN — making Proxmox/Ceph migration compatible with existing inter-site configurations that were at the vSAN tolerance limit.

◆ RISK 3 — MIGRATION SEQUENCING: MANDATORY ORDERHIGH

A stretched cluster migration cannot be done layer by layer independently. The order is mandatory to avoid degrading fault tolerance during transition:

1. D3 infrastructure (QDevice + Ceph MON tiebreaker) → prerequisite for everything else
2. Network (OVN/OVS parallel to NSX-T) → dual-stack during transition
3. Storage (Ceph stretched parallel to vSAN) → VM data migration tier by tier
4. Compute (Proxmox VE parallel to ESXi) → VM migration after storage validated
5. K8s (K3s/K8s after compute) → Velero backup/restore from Tanzu
6. Protection (PBS replacing Veeam/SRM) → last, after full validation

Never decommission vSAN before Ceph stretched is validated in production. The storage double-run period is the most costly but least risky phase.

OPS

PAGE 6 · 5-PHASE MIGRATION PLAN — OPERATIONAL SEQUENCE

5 PHASES · STRICT SEQUENCE · CONTROLLED DOUBLE-RUN

Durations are indicative estimates for a 20-host / 200-VM / 3-site configuration. Your context may vary significantly.

◆

PHASE 0 · AUDIT & PREPARATION (estimate: 4–6 weeks)

CIO/CTO: full VM inventory · Tier 1/2/3 classification · double-run cost calculation · Broadcom contract audit · maintenance window identification · go/no-go decision per layer

SRE/Architect: D1↔D2↔D3 latency measurement · Ceph sizing (OSD/MON/MGR) · Proxmox VE sizing · OVN addressing plan · CRUSH rules definition · inter-site bandwidth validation

PHASE 1 · PARALLEL INFRASTRUCTURE (estimate: 2–4 weeks)

Proxmox VE installation on new hosts (or cohabitation if sufficiently dimensioned) · Corosync cluster D1+D2+QDevice D3 · Ceph MON tiebreaker D3 · Initial Ceph OSD D1 and D2 · Base OVN/OVS configuration · PBS installed and configured. No VMs migrated. Infrastructure validation phase only: simulated split-brain test · Corosync failover test · Ceph quorum test · latency validation.

PHASE 2 · TIER 3 MIGRATION (DEV/TEST) (estimate: 3–4 weeks)

VMDK → qcow2 conversion with virt-v2v or Proxmox import · cold migration of non-critical VMs · Ceph stretched performance validation under real load · live migration validation between D1 and D2 · Ceph failover validation on simulated site loss · team training on Proxmox interface. Network: first OVN segment in production parallel to NSX-T.

PHASE 3 · TIER 2 MIGRATION (NON-CRITICAL PRODUCTION) (estimate: 4–8 weeks)

Migration in batches of 10–20 VMs · Proxmox HA validation on simulated site loss · NSX-T to OVN flow migration segment by segment · OVN ACL validation as NSX DFW equivalent · Tier 2 K8s: Tanzu → K3s migration with Velero. Network: progressive NSX-T → OVN switchover with dual-stack maintained.

PHASE 4 · TIER 1 MIGRATION (CRITICAL PRODUCTION) (estimate: 4–8 weeks)

Planned migration with short maintenance windows (<30 min per batch) · final NSX-T → OVN switchover for critical flows · progressive vSAN deactivation after Ceph production validation · full disaster recovery test D1 → D2 · RPO/RTO validation per tier · documented rollback test. Tier 1 K8s: last migration after full Tier 2 validation.

PHASE 5 · VMware DECOMMISSION (estimate: 2–4 weeks)

Broadcom subscription termination · licence archiving · ESXi host removal · NSX-T manager decommission · vCenter deletion · configuration archiving · final Proxmox architecture documentation · actual vs estimated ROI audit · post-migration software governance audit.

◆ GOLDEN RULE FOR STRETCHED CLUSTER — NEVER DECOMMISSION BEFORE VALIDATION

vSAN must not be decommissioned before Ceph stretched has run in production across all migrated Tiers for at least 4 weeks without incident. NSX-T must not be decommissioned before OVN has managed all production flows for 2 weeks. The double-run cost is the price of safety.

OPS

PAGE 7 · REFERENCE OPEN-SOURCE STACK — 7 LAYERS MIGRATED

FULL MIGRATION TABLE — VMware → OPEN-SOURCE

Portability: F=Full (open standard) · P=Partial (adaptation required) · Effort: L=Low · M=Medium · H=High

◆

Layer · VMware component

Open-source equivalent

Migration method

Effort

Portability

Hypervisor
VMware ESXi + vSphere

Proxmox VE (KVM/QEMU)
proxmox.com · AGPLv3

virt-v2v · OVA import · Proxmox import plugin · cold or live migration

M

F · KVM standard

Distributed storage
vSAN Stretched

Ceph RBD Stretched
ceph.io · LGPL

Export VMDK → qcow2 · RBD pool import · stretched CRUSH rules · D3 MON tiebreaker

H

F · RADOS standard

Network overlay
NSX-T · GENEVE · DFW

OVN + Open vSwitch
ovn.org · ovs.org · Apache 2.0

Segment-by-segment reconfiguration · OVN ACLs · BGP EVPN FRRouting · same GENEVE protocol

H

F · open standards

Cluster orchestration
vCenter · DRS · HA

Proxmox Cluster Mgr + Corosync
QDevice D3 tiebreaker

HA group reconfiguration · fence devices · migration policies · corosync-qnetd QDevice

M

F · Corosync standard

Kubernetes
VMware Tanzu (TKG)

K3s / vanilla K8s
k3s.io · kubernetes.io

Velero backup/restore · Ceph RBD CSI driver · Calico or Cilium CNI · cluster recreation

M

F · CNCF standard

Backup / DR
Veeam · VMware SRM

Proxmox Backup Server (PBS)
+ Velero for K8s

PBS installation · job configuration · retention · encryption · full restore test

M

F · open format

Monitoring / Observability
vRealize / Aria Operations

OTel + Prometheus + Grafana
+ Loki logs

OTel stack installation · Proxmox dashboards · Ceph dashboards · equivalent alerts

L

F · CNCF standard

IaC
vSphere Terraform provider

OpenTofu + Proxmox provider
opentofu.org · telmate/proxmox

Terraform → OpenTofu manifest rewrite · proxmox provider · same HCL logic

M

F · HCL compatible

◆ WHAT YOU GAIN BEYOND COST

Portable skills on open standards (KVM · Ceph · OVN · K8s) · Linux Foundation and CKAD/CKA certifications valued on the wider market · active community (Proxmox Forum · Ceph upstream · OVN GitHub) · enterprise support available (Proxmox GmbH ~€1,400/year/node · Red Hat Ceph Storage) · zero proprietary licence dependency to continue running infrastructure · EU Data Act art. 25 compatible: migration possible at any time without contractual obstacle.

OPS

PAGE 8 · CHANGE MANAGEMENT — VMware SKILLS LOCK-IN

3 RESISTANCE PROFILES · TRAINING PLAN · CERTIFICATIONS

◆

3 VMware-SPECIFIC RESISTANCE PROFILES — NATURE · LEVER · WHAT'S NOT SAID

① THE VCP/VCAP ENGINEER — VMware certified for 3–8 years

Resistance: "My VMware certifications are worthless if we migrate to Proxmox. I spent 3 years earning them."

Lever: KVM/Linux/Ceph/OVN skills are more portable and better compensated than proprietary VMware certifications. CKAD, CKA, Linux Foundation — larger market. Engage them as migration architect: they become the most valuable expert on the project.

What's not said: Their resistance is rational short-term. Over 3–5 years, open skills expose them to a much wider market than Broadcom certifications.

② THE NSX ARCHITECT — VMware network expert

Resistance: "OVN is complicated, I know NSX-T inside out. The project will take twice as long if we change the network."

Lever: OVN uses the same GENEVE protocol as NSX-T. The distributed routing logic is identical. The learning delta is 6–8 weeks, not 6 months. Have them discover OVN alongside NSX-T during the dual-stack phase.

What's not said: Their NSX-T expertise transfers directly to OVN — the concepts are isomorphic. They're often the best OVN trainer on the team after 4 weeks of practice.

③ THE "vCENTER ADDICT" OPS — 5+ years of console comfort

Resistance: "vCenter does everything in clicks. Proxmox is command line — we'll lose productivity."

Lever: Proxmox has a complete, intuitive web interface. Daily operations (create/clone/migrate a VM) are as fast in Proxmox GUI as in vCenter. Command line is a bonus, not a requirement for common ops.

What's not said: vCenter UX was designed to create this dependency. Naming it helps overcome it. A 30-minute live demo is usually enough to reduce the anxiety.

◆ TRAINING PLAN — 3 PHASES · SKILLS MAPPING

Current VMware skill

Open-source equivalent

Delta

Training duration

ESXi / vSphere admin

Proxmox VE + KVM/QEMU

Medium

3–4 weeks

vSAN admin

Ceph admin (OSD/MON/CRUSH)

High

6–8 weeks

NSX-T architect

OVN + OVS + FRRouting

Medium

4–6 weeks

Tanzu / vSphere K8s

K3s / K8s vanilla + Velero

Medium

3–5 weeks

Terraform vSphere provider

OpenTofu + Proxmox provider

Low

1–2 weeks

OPS

PAGE 9 · DECISION GRID · APPROXIMATE ROI

AM I READY TO MIGRATE? · 12 QUESTIONS · SCORE /24

Decision support tool · Not exhaustive · ROI figures are approximate estimates for illustrative purposes only

◆

Q.

Decision question · Yes = 2 pts · No = 0 pt

Layer

1

Has my Broadcom subscription increased by more than 50% since the VMware acquisition?

Pricing

2

Does my current contract include non-cancellable commitments beyond 12 months?

Contractual

3

Is my D1↔D2 latency below 10ms RTT (Ceph stretched compatible)?

Technical

4

Do I have an independent D3 site on a separate network path from D1↔D2 for the tiebreaker?

Technical

5

Does my team have at least 2 advanced Linux engineers capable of administering Ceph?

Skills

6

Do I have Tier 3 VMs (dev/test) without availability constraints to serve as a pilot?

Migration

7

Does my vSAN storage use complex SPBM policies that are difficult to reproduce in Ceph?

Technical

8

Are my NSX-T flows documented (T0/T1 topology, segments, DFW ACLs)?

Network

9

Using Tanzu: are my K8s workloads stateless or with documented persistent storage?

K8s

10

Do I have a budget for 6 months of double-run (VMware + Proxmox in parallel)?

Financial

11

Has my management approved a maintenance window for critical Tier 1 VMs?

Governance

12

Is my current disaster recovery plan documented and tested within the last 6 months?

DR

0–8 pts

Insufficient prerequisites · In-depth audit before decision

9–14 pts

Migration feasible · Start with Tier 3 · Resolve identified gaps

15–18 pts

Migration recommended · 5-phase plan applicable

19–24 pts

Priority migration · Fast ROI · Start Phase 0 immediately

◆ APPROXIMATE ROI — ILLUSTRATIVE EXAMPLE (20 HOSTS · 200 VMs · 3 SITES)

These figures are purely illustrative and approximate — your actual situation may differ significantly based on Broadcom negotiation, hardware sizing and internal migration costs.
Estimated VMware/Broadcom cost (illustrative): €300,000/year (post-Broadcom subscription ×3 on a previous base of €100,000/year).
Estimated Proxmox cost (illustrative): Optional Proxmox GmbH support ~€28,000/year (20 nodes × €1,400) · software licences: €0 (AGPLv3).
Estimated annual saving: ~€272,000/year after full migration.
Estimated migration cost: 6 months double-run (~€150,000 infrastructure) + training/consulting (~€50,000) = ~€200,000.
Estimated ROI: under 9 months after migration completion. These estimates are indicative — recalculate with your actual figures.

OPS

PAGE 10 · TOOLS · RESOURCES · REFERENCES

MIGRATION TOOLS · DOCUMENTATION · COMMUNITIES

◆

◆ VM CONVERSION TOOLS

virt-v2v — VMware VM conversion (VMDK) to KVM (qcow2) · supports ESXi, vCenter · automatic virtio driver handling · libguestfs-tools
qemu-img — manual VMDK → qcow2 conversion · qemu-img convert -f vmdk -O qcow2 vm.vmdk vm.qcow2
Proxmox import plugin — direct import from ESXi datastore via Proxmox interface · available Proxmox VE 8.x
ovftool — VMware export to OVA/OVF · used upstream of virt-v2v

◆ CEPH STRETCHED TOOLS

cephadm — Ceph deployment · recommended for Ceph 16+
crushtool — CRUSH map compilation and validation
ceph mon stretch cluster — stretched mode activation command
radosgw-admin — RGW object management if object storage required

◆ OVN NETWORK TOOLS

ovn-nbctl / ovn-sbctl — OVN North/South database management
ovs-vsctl — Open vSwitch configuration
FRRouting (FRR) — BGP EVPN for inter-site routing
Proxmox SDN — Proxmox interface for OVN (simplifies configuration)

◆ K8s & BACKUP TOOLS

Velero — K8s workload backup/restore · Tanzu → K3s/K8s vanilla migration · vmware-tanzu/velero
K3s — lightweight Kubernetes · ideal <20 nodes · k3s.io
Ceph CSI driver — K8s persistent storage via RBD · github.com/ceph/ceph-csi
PBS (Proxmox Backup Server) — incremental VM backup · deduplication · encryption · free

◆ REFERENCE DOCUMENTATION

Proxmox VE Admin Guide — pve.proxmox.com/pve-docs/
Ceph Documentation — docs.ceph.com · "Stretched Clusters" section
OVN Architecture Guide — ovn.org/documentation
FRRouting docs — docs.frrouting.org · BGP EVPN
RFC 7348 — VXLAN encapsulation
RFC 8365 — EVPN for datacenter interconnect

◆ COMMUNITIES & SUPPORT

Proxmox Community Forum — forum.proxmox.com · very active · fast responses
Ceph Mailing Lists — lists.ceph.io · ceph-users for operational questions
OVN GitHub — github.com/ovn-org/ovn · issues and discussions
Proxmox GmbH Support — ~€1,400/year/node · guaranteed SLA
Red Hat Ceph Storage — enterprise Ceph support

◆ KEY COMMANDS — QUICK START

      # VMDK → qcow2 conversion

      virt-v2v -i vmx vm.vmx -o local -os /var/lib/vz/images/100/

      # Ceph stretched mode activation

      ceph mon enable_stretch_mode <tiebreaker_mon> datacenter

      # Corosync QDevice on D3

      pvecm qdevice setup <qdevice-ip>

      # Live VM migration D1 → D2

      qm migrate <vmid> <target-node-d2> --online --with-local-disks 0

This guide is a generic technical study. Configurations are illustrative.
It does not constitute individualised engineering advice.
Nemo supra legem est
Amine RAITI · Infrastructure Architect & SRE · Public document · CC BY-NC-SA 4.0 · AI Powered by Amine