From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 4189F1FF09B for ; Mon, 31 Aug 2026 09:11:22 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 13452213ED; Mon, 31 Aug 2026 09:11:22 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=f9cROCIjeSlUilMlHD/ampoE/Y0BvFU62C/O3iZZo6YoueE1jJmz1Yxq24Pg5M8pgr4potBcaGxRZcLAJA67MDy9eMvl6dxLjwM2ZVkDzVQMzFQ3dZ0f2Pb2HC+3vE0sk2eMcVcRwcpzaD8Si4ZjZpX5eCCl8bKrbRppemxRuSg/RJqH5Y2gHSvhNlFtnCEuj3eF+pzePJChAxi3ZkWf6RN7BvHrjXGto1zziCvOsOeHLjmoiAj+bolHZy9RwVVzqNB9Cq1BBftlSCWe7eCjC6/FRLkhgaArqldX2p17r83Es1U3sXwhKHATmMAQCyJ2btNUiAn44NZATXIy3xnh8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6zD/h79IR6omYqJCO5ci+01QBt1KOOAG9xG4wVbcVhQ=; b=RG5+jEylMb3VnHCdTW/4GoDJa89ALUFHtYvpF3WIyXmVV+uuWqgXqaB79RfLWbZ3WlrOPpsI4uz94A0pkn+6kCKdOuMCafPLetQcfelJasuqEK/0G5ThJovc+Qddmu1ZIzLsyDCY3jKw06K7KfMRAF8/v7g+VgIXiToqczoOzg0Serece3yo74lcwrjqQ1QfqxUOKrsvscUTyDc0YBdoaqMecorypNvu26Uv+D7DpY7HJ4VejXvK9Ak2CMV6mP2ylZ2v16z+ZX/xLTVCngSGxW1wQCob4MGOq43IKa4QTNsI1eAv5iXG1YTUXfKRebuWaYaPvWJ1Iy9/hCE2PvnhkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sword-group.com; dmarc=pass action=none header.from=sword-group.com; dkim=pass header.d=sword-group.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sword-group.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6zD/h79IR6omYqJCO5ci+01QBt1KOOAG9xG4wVbcVhQ=; b=MvyzObbvwtxa5LcwQKv+M0wXzTaXPNy0bIGAW6aD90ebfkkVcAcat+72M7t11OXI0dvneTNmuSyxhTTUZPlLuyFwCBYsxtFjWNiWv9vsIQ6vZ6jR45OqmDg+sSwUWVxv5HuPDBlV+Ino05om66u+kTuYBhUmVyRAjrAHjAdNKjoAM/1jZrfW/N9AwF5LSp5x4JUPy5EfYdbwEcbhb59MAYvkepCXQqHJhgdv0VHLugQQ4O9seAbXqnc2IVxok2hJTgL9yrMKge1ug10FFIges46sBjUjEnNMuxiWvCYbgkFhBkcC/vAzOjvGj9exVoAtVcW3TDrKgaEQUmoGTPtdng== From: LIONNETON Vincent To: "pve-devel@lists.proxmox.com" Subject: [RFC] VMware/NSX to Proxmox migration: policy transformation and staged network handoff Thread-Topic: [RFC] VMware/NSX to Proxmox migration: policy transformation and staged network handoff Thread-Index: AQHdORXHyt2nRfnSlUqZNK7+3ZBZYw== Date: Mon, 31 Aug 2026 07:11:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=sword-group.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU5PR08MB10400:EE_|GVXPR08MB10614:EE_ x-ms-office365-filtering-correlation-id: b7400b01-43f1-42e7-c8c2-08df072f05ec x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|18002099003|56012099006|3023799007|8096899003|38070700021|11063799006|6133799003|10067099003; x-microsoft-antispam-message-info: Yl7bXit8Uhzom3Vcb6StUR3ednZfPu+eNG5OYHs0frjNP/sf9+W3/5SJ1BSrDgXtbo1CoLX55K4ALN0Q2+wEM7oEykyPAU3s1QS4EH4YgXn3rmGveZW1gxwYH3A9MTC+7ebdZ9fn/M6GiuswjX2Age3c+9Vi1D3s7ZiMBWeMz8prOmk/RAT1xSiCSudEHcHtxOpTJe7ripjwrpvWhGW4ATuXommMbsAEt5iIj+b6JEuv80dCx7l9GdUvgG4+TTdUyqxbblqjhs5N/nfF9/ToJda7hM5bON1xQPvMW6s3zykX65ckXdXfmaw37p59wqSAbyXTh1+z70ndIWkC3OBrGfZF3IdW5GmQHFFUufYCAfqg3Vw4IqvhBx9QlqBztN1iT/Im9SEDkXv70jCzZMZLVcv0ZQlddwqXYMeqbV628XvGSik75pl90m4kKuvIOL+lK0CgO/yFZ3ukPvFbzfovk4LyQlrL9mihzCOA6MsLGP4k7GfDm7/nKrG3FPNwX+RCRdmgMlaD2OzrAe7vnpbXXeNMxcLfKMr8nCDENIHjGS/khLOX8P4ddzHHIp9rRFtknXVNG5XL0aUCmPfLmNzG2sjFC6qkk5aGz2a7A97/YgSdR0k7uI3EGPMmU+Y5ER0Xonpiv33L5KeycGSY2eoFDxxBO8rhcwyiNYewdIsylGg= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU5PR08MB10400.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(18002099003)(56012099006)(3023799007)(8096899003)(38070700021)(11063799006)(6133799003)(10067099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?HokUjybPn9Pk+DG+x+9peitzcuDIKYZsIOLIZTxUm1moVqGVs5EBAQKwNn?= =?iso-8859-1?Q?8Gouw13jRw4iquzVagYVE4zo3aDr0SdaLMrEZvTIpO7zK3EqfIgq9j3a5D?= =?iso-8859-1?Q?dRBu/VO55uhfoFrMvxRNn2HVolIxM67JjpM0M3fLR+FYsMntrq58shh6Fe?= =?iso-8859-1?Q?gSK8An0hMOl4hZqab+EQMc99+6h8BDPVDIRS8WsurNlpf3HxTcixSeCrdd?= =?iso-8859-1?Q?oJSTqzUK9v5N82Kxb9VXdrfen8M+3VvQxVHgX+Rg/2cZLhmLqqkSnsJ4xE?= =?iso-8859-1?Q?9Q/Mwu/cpb9pYNDZdmXlLMhJHX1kBpTUGygzTU4rlm6l167Oeu+RJYpfnS?= =?iso-8859-1?Q?kKVuFaOevNORtwp26J5GSIJdFRtIf55UPj0es3LuGxxsGjTHEOriFYO9vh?= =?iso-8859-1?Q?hlpl9568j1pFAK9hMVGLCnDBTHPNri1KtKG/UOUQM2trM3BtuhIIntbqyc?= =?iso-8859-1?Q?WQdqfFIx+4i2buWe263nbC8yOVcyo24o5r4fi2cWXolZlmSsU8T34RTBYy?= =?iso-8859-1?Q?Hwyjqxbi9ZGB/je82XtKMryzPwnYnE5izl3Ln1ya83xJ8mJV1UAj1Ew8Zz?= =?iso-8859-1?Q?bgaW6FSXUL4zDVRuVMB0+iw1QVwgLWp2NbelNeQ/SFxuHZJCjcfVwNT1p5?= =?iso-8859-1?Q?OvsOCdHx8eh29kqxD457fY5H1/dcMP/v9a9gCS+bvVWVG/ZfTllMy45M27?= =?iso-8859-1?Q?3HsdMTPvustxdbzQy6wOR5npA17bv7eUpK7VTtz8+qv2N4LpxBnI3oJLeQ?= =?iso-8859-1?Q?zv0fyx82Y9bthxAp9ix0e7aejT7nlwpX17EcRfxATaGNXtzyr7rNv8wc5T?= =?iso-8859-1?Q?3kQp0c6HxsCsGKRm2TqDezOd00TnGkDp2nhGrV6qBzhDqUpjrNb4JUa/er?= =?iso-8859-1?Q?INZIqZ50+jXIhreYbXUGi81Df19sZQRO2ZNv1BjE1rnntAeoLmBb0aN+YH?= =?iso-8859-1?Q?/PrA2qpia8CqLMt4ctioMGpUoulNUEyf7tMKVKzeefrl3wz5A8EQh/A7U/?= =?iso-8859-1?Q?Q1sLF+SWHfs0lYFGSUXwto2t3VPj4Fh2QvwcfwoG+XVqE/VGt7BOpHnQDS?= =?iso-8859-1?Q?5yrFdxKS+goi5dSCro2ort7uT8dli7LNF29PYqhm3JV0r5YyMfkeOt3aGD?= =?iso-8859-1?Q?L3Onvt5N2aDUIMYWv34xK9QdsSGIsVRqXWafoF+DXs0R1Fs1UqqZF7eX/Z?= =?iso-8859-1?Q?GMgVHHm3E35jguo0sQyZI6M3kKO3JMKV1ulXgbVlDzVloxRO+uOtf6g4Mx?= =?iso-8859-1?Q?TWFphbpd4n8Xj8lDeZDCoinr5kd02SsAUUh+MbKMAVrpsIdMLUezIIjU51?= =?iso-8859-1?Q?cna8SPfOANbMnv4nDD9pvmr4S9lCubOeGgi2wbZElkLsG5ogCYxV5FnK+b?= =?iso-8859-1?Q?HgdCySZsJ5FY47Zb6c+avPMLiLt//Hil3Co68kNq0ki/gZNH400fqiqd5Q?= =?iso-8859-1?Q?lux7/q849lgOz+LfdKt5C3BbQ1EWjHm5JnDC68ZBhlRq2dVfCZZEBFF5kA?= =?iso-8859-1?Q?8zMWiiSVEo8lVP5l+HpCu0WG/82NFBm4FqeRTKSjFCIlKgpYX58ApZwJFB?= =?iso-8859-1?Q?qggU6q5gMNGeCQlobVyT1eDF/ONX5iNtIojGCRje7nwXjQwIxK8zvRuh+C?= =?iso-8859-1?Q?AJG+AveMRxP1yQehGD9/8K4IH1qYSSoh550oIKRrG6YwUfhmB+8w63eqba?= =?iso-8859-1?Q?EkEGfOXE9H2EMc72VPb6MSWBStD73MSPIMXClZnFYK5S8SrXS59ESQpOOD?= =?iso-8859-1?Q?XbqNe4FOO23tq/qFbKzycmJ+eBwyzwkeIFdVLRgYkJr0ZXepWAREROiC1u?= =?iso-8859-1?Q?987wXYzPXZTX8fmIfKLHbPQhhE2ZE04=3D?= Content-Type: multipart/alternative; boundary="_000_DU5PR08MB1040084C7A24851CED4253C5AA3A92DU5PR08MB10400eu_" MIME-Version: 1.0 X-OriginatorOrg: sword-group.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU5PR08MB10400.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7400b01-43f1-42e7-c8c2-08df072f05ec X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2026 07:11:05.3520 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6adf23d8-eabe-44c8-b68a-0b8fb7aacef9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rgGGg/3vgVUkmqQsrWYYUKOK//EUjJi+JxpUCYvS/JgvHr2ri9+I1JiynarRBcBbbE3/HGTrawQvmzHhgSsXxtvylsGh+x84mdQ6FUrrz9KOAFmShnuLdWC8KGhTldY3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB10614 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.125 Adjusted score from AWL reputation of From: address DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy HTML_MESSAGE 0.001 HTML included in message RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust SPF_HELO_PASS -0.001 SPF: HELO matches SPF record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: PKAIZ7472MZBXEOMKHBCTH7OBISQJD73 X-Message-ID-Hash: PKAIZ7472MZBXEOMKHBCTH7OBISQJD73 X-MailFrom: vincent.lionneton@sword-group.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "pdm-devel@lists.proxmox.com" X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_DU5PR08MB1040084C7A24851CED4253C5AA3A92DU5PR08MB10400eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I would like to get some feedback from the Proxmox development team before = we invest further development effort into a VMware/NSX-to-Proxmox migration= project, in particular to avoid duplicating functionality that may already= be planned for PVE or PDM. We are currently evaluating large-scale migrations from VMware vSphere + NS= X to Proxmox VE. The existing ESXi importer already provides a solid foundation for VM migra= tion, while PVE SDN/firewall and the ongoing PDM development increasingly p= rovide the target networking and security control plane. We are currently testing different approaches and are particularly interest= ed in the transition from the VMware/NSX environment to a native Proxmox en= vironment, rather than building another permanent Proxmox network/security = controller. One migration model we are considering would be : * discover vCenter and NSX inventory: VMs, networks/segments, IP/MAC informat= ion, groups/tags, services and DFW policies; * Understand and resolve the effective NSX security policy applicable to each= workload; * migrate workloads to PVE while preserving their existing IP addressing when= ever possible, using temporary L2 coexistence between NSX and PVE; * translate the effective NSX DFW policy into native PVE firewall objects suc= h as Security Groups, IP sets and VM/VNet firewall rules; * translate workload-centric rules with the appropriate direction semantics, = for example source membership to PVE OUT policy and destination membership = to PVE IN policy; * validate security-policy and network-flow parity between the source NSX env= ironment and PVE during coexistence; * progressively hand over each network's gateway/routing from NSX to PVE SDN/= EVPN/BGP; * provide pre-checks and rollback at the VM, security and network-cutover sta= ges; * leave no permanent runtime dependency on the migration tool once the VMware= /NSX environment has been retired. We are currently experimenting with VM migration, PVE SDN/EVPN connectivity= and the feasibility of translating NSX security groups and policies into n= ative PVE firewall constructs. Before going further, particularly with same-address coexistence and networ= k handoff, I would appreciate Proxmox's guidance on the following points: 1. Is NSX-aware migration already planned or being worked on within Proxmox= , publicly or internally? In particular, are there plans around NSX DFW/security-policy migration, NS= X network preservation, or staged migration from NSX networking to PVE SDN? 2. Do you see this functionality primarily as an external migration/transfo= rmation tool using PVE/PDM APIs, or do some of these functions belong in PV= E or PDM themselves? We explicitly do not want to develop a competing permanent SDN/firewall con= trol plane if PDM is intended to provide that functionality. 3. For an external migration tool, what would you consider the preferred an= d sufficiently stable API integration points? In particular for VM migration, SDN/VNet provisioning, EVPN/BGP configurati= on, Security Groups/IP sets, guest/VNet firewall policies and multi-cluster= orchestration through PDM. 4. Would effective NSX-policy translation and policy-parity validation be u= seful functionality from Proxmox's perspective? For example, resolving dynamic NSX group memberships and the effective DFW = policy for a VM, compiling that intent into native PVE firewall objects, an= d comparing the resulting effective policy before cutover. 5. Does the proposed same-address migration model fit the intended PVE SDN = architecture? The idea is to temporarily extend the existing NSX L2 network to PVE, migra= te the workloads while keeping IP/gateway addressing unchanged, and only la= ter hand the gateway/routing function over from NSX to PVE EVPN/BGP on a ne= twork-by-network basis. 6. Is low-downtime/incremental VMware migration already in scope for the ex= isting importer? We are particularly interested in whether a VDDK/CBT-style precopy/delta me= chanism, or another warm-migration mechanism from ESXi, is already planned. 7. Are there generic PVE/PDM capabilities that would be useful to implement= upstream for this use case? Possible examples are effective-firewall-policy inspection, policy diff/val= idation, dry-run APIs, structured external-migration prechecks, or bulk fir= ewall/IP-set operations. 8. If some of these pieces would be appropriate upstream, where would you p= refer them to live and what development interfaces/conventions should we ta= rget? For example PVE vs PDM, the appropriate repositories and APIs, Rust vs exis= ting PVE components, expected test coverage and contribution workflow. Our intention would be to keep all VMware/NSX-specific discovery and transf= ormation logic in the migration tooling, while contributing only genuinely = generic Proxmox capabilities upstream if that is of interest. Once the migration is complete, the resulting environment should consist so= lely of native PVE/PDM SDN and firewall configuration and should not depend= on the migration tool for normal operation. I would be happy to share a more detailed architecture or the results of th= e current proof of concept if useful. Best regards, Vincent LIONNETON Infrastructures Consultant Sword Switzerland +41(0)22 594 91 16 vincent.lionneton@sword-group.com Business Park Terre-Bonne, B=E2timent A1, Route de Crassier 7, 1262 Eysins = (Nyon) sword-group.com Follow us on LinkedIn = | YouTube | Twitter/X | Facebook This message and all attachments are for the exclusive use of the recipient= s and are confidential. If you receive this message in error, please destro= y it and immediately notify the sender and/or privacy@sword-group.com. Any use of this message that does not conform t= o its destination, any distribution or publication, in whole or in part, is= prohibited, unless expressly authorised. As the Internet cannot ensure the= integrity of this message, Sword Group (and its subsidiaries) declines all= responsibility with regard to this message, in the event that it has been = modified, altered or falsified. Sword Group thanks you for your attention. --_000_DU5PR08MB1040084C7A24851CED4253C5AA3A92DU5PR08MB10400eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,

I would like to get some feedback from the Proxmox development team before = we invest further development effort into a VMware/NSX-to-Proxmox migration= project, in particular to avoid duplicating functionality that may already= be planned for PVE or PDM.

We are currently evaluating large-scale migrations from VMware vSphere + NS= X to Proxmox VE.

The existing ESXi importer already provides a solid foundation for VM migra= tion, while PVE SDN/firewall and the ongoing PDM development increasingly p= rovide the target networking and security control plane.

We are currently testing different approaches and are particularly interest= ed in the transition from the VMware/NSX environment to a native Proxmox environme= nt, rather than building another permanent Proxmox network/security con= troller.

One migration model we are considering would be :

  • discover vCenter and NS= X inventory: VMs, networks/segments, IP/MAC information, groups/tags, servi= ces and DFW policies;
  • Understand and resolve = the effective NSX security policy applicable to each workload;
  • migrate workloads to PV= E while preserving their existing IP addressing whenever possible, using te= mporary L2 coexistence between NSX and PVE;
  • translate the effective= NSX DFW policy into native PVE firewall objects such as Security Groups, I= P sets and VM/VNet firewall rules;
  • translate workload-cent= ric rules with the appropriate direction semantics, for example source memb= ership to PVE OUT policy and destination membership to PVE IN policy;
  • validate security-polic= y and network-flow parity between the source NSX environment and PVE during= coexistence;
  • progressively hand over= each network's gateway/routing from NSX to PVE SDN/EVPN/BGP;
  • provide pre-checks and = rollback at the VM, security and network-cutover stages;
  • leave no permanent runt= ime dependency on the migration tool once the VMware/NSX environment has be= en retired.


We are currently experimenting with VM migration, PVE SDN/EVPN connectivity= and the feasibility of translating NSX security groups and policies into n= ative PVE firewall constructs.

Before going further, particularly with same-address coexistence and networ= k handoff, I would appreciate Proxmox's guidance on the following points:


1. Is NSX-aware migration already planned or being worked on within Prox= mox, publicly or internally?

In particular, are there plans around NSX DFW/security-policy migration, NS= X network preservation, or staged migration from NSX networking to PVE SDN?=

2. Do you see this functionality primarily as an external migration/tran= sformation tool using PVE/PDM APIs, or do some of these functions belong in= PVE or PDM themselves?

We explicitly do not want to develop a competing permanent SDN/firewall con= trol plane if PDM is intended to provide that functionality.

3. For an external migration tool, what would you consider the preferred= and sufficiently stable API integration points?

In particular for VM migration, SDN/VNet provisioning, EVPN/BGP configurati= on, Security Groups/IP sets, guest/VNet firewall policies and multi-cluster= orchestration through PDM.

4. Would effective NSX-policy translation and policy-parity validation b= e useful functionality from Proxmox's perspective?

For example, resolving dynamic NSX group memberships and the effective DFW = policy for a VM, compiling that intent into native PVE firewall objects, an= d comparing the resulting effective policy before cutover.

5. Does the proposed same-address migration model fit the intended PVE S= DN architecture?

The idea is to temporarily extend the existing NSX L2 network to PVE, migra= te the workloads while keeping IP/gateway addressing unchanged, and only la= ter hand the gateway/routing function over from NSX to PVE EVPN/BGP on a ne= twork-by-network basis.

6. Is low-downtime/incremental VMware migration already in scope for the= existing importer?

We are particularly interested in whether a VDDK/CBT-style precopy/delta me= chanism, or another warm-migration mechanism from ESXi, is already planned.=

7. Are there generic PVE/PDM capabilities that would be useful to implem= ent upstream for this use case?

Possible examples are effective-firewall-policy inspection, policy diff/val= idation, dry-run APIs, structured external-migration prechecks, or bulk fir= ewall/IP-set operations.

8. If some of these pieces would be appropriate upstream, where would yo= u prefer them to live and what development interfaces/conventions should we= target?

For example PVE vs PDM, the appropriate repositories and APIs, Rust vs exis= ting PVE components, expected test coverage and contribution workflow.

Our intention would be to keep all VMware/NSX-specific discovery and transf= ormation logic in the migration tooling, while contributing only genuinely = generic Proxmox capabilities upstream if that is of interest.

Once the migration is complete, the resulting environment should consist so= lely of native PVE/PDM SDN and firewall configuration and should not depend= on the migration tool for normal operation.

I would be happy to share a more detailed architecture or the results of th= e current proof of concept if useful.


Best regards,


 

 

Vincent LIONNETON
Infrastructures Consultant

 

 

 

Sword Switzerland
+41(0)22 594 91 16

vincent.lionneton@sword-group.com  

Business Park Terre-Bonne, B=E2timent A1, Route de Crassier 7,= 1262 Eysins (Nyon)

 

 

sword-group.com

Follow us on LinkedIn | <= u>YouTube  | Twitter/X | Facebook

 

 

This message and all attachments are for the exclusive use o= f the recipients and are confidential. If you receive this message in error= , please destroy it and immediately notify the sender and/or privacy@sword-group.com. Any use of this message that does not c= onform to its destination, any distribution or publication, in whole or in = part, is prohibited, unless expressly authorised. As the Internet cannot en= sure the integrity of this message, Sword Group (and its subsidiaries) declines all responsibility with regard= to this message, in the event that it has been modified, altered or falsif= ied. Sword Group thanks you for your attention.

 

 

--_000_DU5PR08MB1040084C7A24851CED4253C5AA3A92DU5PR08MB10400eu_--