[RFC] VMware/NSX to Proxmox migration: policy transformation and staged network handoff

[RFC] VMware/NSX to Proxmox migration: policy transformation and staged network handoff

[LIONNETON Vincent]

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 + NSX to Proxmox VE.

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

We are currently testing different approaches and are particularly interested in the transition from the VMware/NSX environment to a native Proxmox environment, 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 information, 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 whenever possible, using temporary L2 coexistence between NSX and PVE;
  *
translate the effective NSX DFW policy into native PVE firewall objects such 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 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 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 native PVE firewall constructs.

Before going further, particularly with same-address coexistence and network 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, NSX network preservation, or staged migration from NSX networking to PVE SDN?

2. Do you see this functionality primarily as an external migration/transformation 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 control 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 configuration, 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 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, and 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, migrate the workloads while keeping IP/gateway addressing unchanged, and only later hand the gateway/routing function over from NSX to PVE EVPN/BGP on a network-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 mechanism, 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/validation, dry-run APIs, structured external-migration prechecks, or bulk firewall/IP-set operations.

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

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

Our intention would be to keep all VMware/NSX-specific discovery and transformation 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 solely 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 the 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<mailto:jerome.spinelly@sword-group.com>

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





sword-group.com<https://www.sword-group.com/fr/>

Follow us on LinkedIn<https://www.linkedin.com/company/sword-group/posts/> | YouTube<https://www.youtube.com/@swordgroup692/featured>  | Twitter/X<https://twitter.com/Sword_Group> | Facebook<https://www.facebook.com/SwordGroup>





This message and all attachments are for the exclusive use of 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<mailto:privacy@sword-group.com>. Any use of this message that does not conform to 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.

Re: [RFC] VMware/NSX to Proxmox migration: policy transformation and staged network handoff

[Stefan Hanreich]

Thanks for your inquiry, I tried to keep the answers relatively short without
diving too much into technical details.

On 8/31/26 9:11 AM, LIONNETON Vincent wrote:

[snip]

> Before going further, particularly with same-address coexistence and network 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, NSX network preservation, or staged migration from NSX networking to PVE SDN?

There are currently no plans for extending the importer functionality to migrating NSX
objects / entities, so efforts on developing something like that would be welcome.

> 2. Do you see this functionality primarily as an external migration/transformation 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 control plane if PDM is intended to provide that functionality.

Optimally, the functionality is implemented natively in PVE / PDM and then only managed
by the external tool. For your purposes, the most interesting things that are still in 
development are VRF support and microsegmentation, which both have a RFC on the mailing
list. Looking at those should give you a good glimpse into our development workflow and
the current codebase.

> 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 configuration, Security Groups/IP sets, guest/VNet firewall policies and multi-cluster orchestration through PDM.

The whole REST API, as described in the documentation [1], is considered to be stable and 
does not introduce breaking changes during a major version. Our policy on what we deem a 
breaking API change and how we treat evolving the API can be found in our Wiki [2].

> 4. Would effective NSX-policy translation and policy-parity validation be 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, and comparing the resulting effective policy before cutover.

For that particular purpose, the ongoing work on microsegmentation is likely of
interest to you [3] as that should provide the functionality required. As it's in
a stage of development, feel free to chime in and test the functionality - we always
value feedback and in this early stage it's a good opportunity for you to check out
the implementation to see if it fits the use-case.

> 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, migrate the workloads while keeping IP/gateway addressing unchanged, and only later hand the gateway/routing function over from NSX to PVE EVPN/BGP on a network-by-network basis.

That should work generally and I know of some customers that have done a similar setup, but
I personally have zero practical experience with this - so it's hard for me to talk about
details. Since standard routing protocols are involved the integration should work, but I
can imagine needing something like a translation layer, i.e. when using a route reflector
for both PVE / NSX-T the routes might need to get transformed by the reflector to match what
the respective stacks expect. Potentially even a router in front of the PVE cluster, that
handles NSX-T / Proxmox VE specifics during the migration. With the recently introduced
route maps feature, this might be possible on the PVE side via the SDN stack solely.

There's very likely a few pitfalls that'd need to be worked out. Ir's very likely that some
setups are currently impossible to model with the SDN stack alone and an external router or
custom FRR configuration is needed - although we're working hard on addressing those
deficiencies. I'd start with attempting to migrate relatively simple setups (e.g.
single-tenant) and see how everything works out for simpler setups.
 
> 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 mechanism, or another warm-migration mechanism from ESXi, is already planned.

There has been some work done internally on improving the importer by utilizing NFC/CBT,
but it still needs a bit of work to drag it over the finish line, I cannot provide
an ETA at this point.

> 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/validation, dry-run APIs, structured external-migration prechecks, or bulk firewall/IP-set operations.

Yes, I would see all of those capabilities as something that should be provided by
the Proxmox VE API and then consumed by your tool. The firewall currently does not
support staging changes, as the configuration is applied continously by the firewall
daemon. SDN itself already has a dry-run API that has been recently introduced [4]
and the related endpoints all support querying the current / pending configuration
via the pending / running GET parameters.

I'm currently working on improving firewall configuration handling together with
a colleague, but the general mechanism stay the same. For the use-cases you mentioned
that would require implementing some sort of staging mechanism for firewall changes.
I'm not sure what you mean with bulk firewall / IP-set operations exactly?

> 8. If some of these pieces would be appropriate upstream, where would you prefer them to live and what development interfaces/conventions should we target?
> 
> For example PVE vs PDM, the appropriate repositories and APIs, Rust vs existing PVE components, expected test coverage and contribution workflow.

Development of Proxmox VE (and other products) happens out here in the open on the
respective mailing lists. We have a short introductory guide to our workflow in the
Wiki [5]. Discussion of specific features usually happens in our bug tracking
instance [6], rather than here on the mailing list directly.

For the SDN stack in particular, new features are implemented in Rust and only
exposed via our perlmod module, which allows calling into Rust code. The new
firewall daemon is implemented in Rust as well, but the API still lives on the
Perl side. That might change in the future though, as we plan on implementing
more and more new features in Rust while also porting existing functionality
over where it makes sense. In the short to mid-term we also want to work on
eliminating the need for Perl to act as a middle man for Rust.


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

That would be the preferred way, in my opinion.

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

Yes, I think there are two phases to this? First, the network topology / structure
would need to get set up on PVE (and hooked up with its NSX-T counterparts) - then
the migration of the VMs and their network configuration, which maps the guest
configuration from VMWare onto the SDN entities. The tool would need to maintain
some form of mapping in that case / or it'd need to be stored in the SDN stack
directly - so the tool can consume that (which is preferable imo).

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

Yes, I'd be interested in that!


[1] https://pve.proxmox.com/pve-docs/api-viewer/
[2] https://pve.proxmox.com/wiki/Proxmox_VE_API#API_Stability_&_Breakage
[3] https://lore.proxmox.com/all/DKRAX8JGPAP2.19JLE3T7U6DS1@proxmox.com/
[4] https://pve.proxmox.com/pve-docs/api-viewer/#/cluster/sdn/dry-run
[5] https://pve.proxmox.com/wiki/Developer_Documentation
[6] https://bugzilla.proxmox.com/