Full Recovery for Proxmox VE and SDN

[Gavino]

The Proxmox Full Recovery for Proxmox VE leaves a lot to be desired when it comes to Network Selection. I only have these options:

But they are no good to me. I use SDN VNets.   These all set a VLAN tag on either of vmbr1 (for my "VMmain" zone) or vmbr4 (for my "VMfwlan" zone):

One example is of my hosted firewall with for virtual NICSs

the first of the vNICs uses the vmbr directly (vmbr3), but the rest reference the SDN VNets.

So the Nakivo restore option really should list all my SDN VNet IDs as well as the vmbr bridges.

Even better why can't Nakivo default to whatever the VM was using when it was backed up?  I've always wondered why I have to manually put this information in?  It's annoying enough when it's just the one vNIC. But it's annoying on multiple levels when there are multiple vNICs, AND I can't even choose the VNet names.

This part of the Nakivo B&R product needs a lot of work, as I've always found it a major pain point.

Edited October 11, 2025 by Gavino

[The Official Moderator]

On 10/11/2025 at 8:55 AM, Gavino said:

The Proxmox Full Recovery for Proxmox VE leaves a lot to be desired when it comes to Network Selection. I only have these options:

But they are no good to me. I use SDN VNets.   These all set a VLAN tag on either of vmbr1 (for my "VMmain" zone) or vmbr4 (for my "VMfwlan" zone):

One example is of my hosted firewall with for virtual NICSs

the first of the vNICs uses the vmbr directly (vmbr3), but the rest reference the SDN VNets.

So the Nakivo restore option really should list all my SDN VNet IDs as well as the vmbr bridges.

Even better why can't Nakivo default to whatever the VM was using when it was backed up?  I've always wondered why I have to manually put this information in?  It's annoying enough when it's just the one vNIC. But it's annoying on multiple levels when there are multiple vNICs, AND I can't even choose the VNet names.

This part of the Nakivo B&R product needs a lot of work, as I've always found it a major pain point.

NAKIVO does not officially support Proxmox SDN features. 

Currently, we support “standard” Proxmox VE networking (bridged network devices, etc.), but SDN introduces extra layers that may or may not be fully supported or work seamlessly.

We can log an improvement request to add such a possibility to the product in the future. 

Please let us know how valuable it is for you.
 

[Gavino]

I have 7 client VLANs  - 3 for wired networks - 3 for wifi networks, and 1 for test.  I also have a few different bridges, so that my virtualized firewalls have dedicated interfaces off each Proxmox node. Having the VNet name means that at a glance - we can easily see what each VM is connected to.  There's no way we want to add a new physical port every time we add a new VLAN. We use trunk ports. In vSphere this is called Virtual Switch Tagging, or VST.

1. External Switch Tagging (EST). The proxmox vmbr bridges aren't VLAN-aware, and the network switches (not Proxmox) handle all the VLANs. This doesn't scale well, as it requires a physical NIC per VLAN.
2. Virtual Switch Tagging (VST). Very common, and probably the most common way of setting things up. This is where VLANs are trunked into Proxmox and the Proxmox mode handles the VLANs - guest VMs and containers don't know about them. This is what we use for almost all our vNICs, barring one firewall vNIC. Proxmox vmbr bridges are VLAN-aware.
3. Virtual Guest Tagging (VGT) - where tagged frames are passed all the way to the guest VMs / containers. I don't use this, but have in the past. Again, Proxmox vmbr bridges are VLAN-aware.

And this is all without SDN on Proxmox - I can only see that Nakivo supports the first type - the very limiting EST.

If it did support VLANs on the Linux bridges (with VLAN IDs, and ideally VNet names), then I would not have to add caveats to my disaster recovery flash VM boot jobs. At the moment I have to make sure that they don't start the VM. Because after the job runs, I have to shut down the VM. Then update the NIC with the correct VLAN settings, before I can start it. That costs time and money and risk in our environment as I have to train all the techs to do that workaround.

What needs to happen, is for the VLAN info to be properly recorded in the Flash VM boot settings, so we can just fire up the job and the VM can start up and get working, with no tedious meddling with settings which slows down disaster recovery, and increases the risk if someone doesn't know the right bridge and or VLAN ID.  With SDN, you don't have to remember any of that - the Bridge and VLAN ID is basically encoded in the VNet name. There's more I could say on the benefits of this, but that will do for now. Thanks.

 

[The Official Moderator]

On 10/15/2025 at 10:09 AM, Gavino said:

I have 7 client VLANs  - 3 for wired networks - 3 for wifi networks, and 1 for test.  I also have a few different bridges, so that my virtualized firewalls have dedicated interfaces off each Proxmox node. Having the VNet name means that at a glance - we can easily see what each VM is connected to.  There's no way we want to add a new physical port every time we add a new VLAN. We use trunk ports. In vSphere this is called Virtual Switch Tagging, or VST.

1. External Switch Tagging (EST). The proxmox vmbr bridges aren't VLAN-aware, and the network switches (not Proxmox) handle all the VLANs. This doesn't scale well, as it requires a physical NIC per VLAN.
2. Virtual Switch Tagging (VST). Very common, and probably the most common way of setting things up. This is where VLANs are trunked into Proxmox and the Proxmox mode handles the VLANs - guest VMs and containers don't know about them. This is what we use for almost all our vNICs, barring one firewall vNIC. Proxmox vmbr bridges are VLAN-aware.
3. Virtual Guest Tagging (VGT) - where tagged frames are passed all the way to the guest VMs / containers. I don't use this, but have in the past. Again, Proxmox vmbr bridges are VLAN-aware.

And this is all without SDN on Proxmox - I can only see that Nakivo supports the first type - the very limiting EST.

If it did support VLANs on the Linux bridges (with VLAN IDs, and ideally VNet names), then I would not have to add caveats to my disaster recovery flash VM boot jobs. At the moment I have to make sure that they don't start the VM. Because after the job runs, I have to shut down the VM. Then update the NIC with the correct VLAN settings, before I can start it. That costs time and money and risk in our environment as I have to train all the techs to do that workaround.

What needs to happen, is for the VLAN info to be properly recorded in the Flash VM boot settings, so we can just fire up the job and the VM can start up and get working, with no tedious meddling with settings which slows down disaster recovery, and increases the risk if someone doesn't know the right bridge and or VLAN ID.  With SDN, you don't have to remember any of that - the Bridge and VLAN ID is basically encoded in the VNet name. There's more I could say on the benefits of this, but that will do for now. Thanks.

 

Thank you for bringing this to our attention. We appreciate your feedback, and we are sorry for any inconvenience caused.

After reviewing the information provided, we have determined that the issue requires the attention of our Development Team.

The data has been forwarded to our Development Team for further investigation, and they are currently reviewing it.

We are actively working on resolving this issue and providing a solution as quickly as possible. 

Thank you for your patience and understanding. In the meantime, if you have any other questions or concerns, feel free to contact our support team at support@nakivo.com.

[Gavino]

Thank you so much, and I appreciate the support. I know that Proxmox compatibility is very recent in the general scheme of things, and so understand that development is ongoing. I look forward to all the improvements that's coming down the pipe. Unfortunately I was too busy to get involved with the 11.1 beta, but will endeavour to get involved with future beta releases, and provide feedback. Cheers.

[The Official Moderator]

On 10/16/2025 at 3:40 PM, Gavino said:

Thank you so much, and I appreciate the support. I know that Proxmox compatibility is very recent in the general scheme of things, and so understand that development is ongoing. I look forward to all the improvements that's coming down the pipe. Unfortunately I was too busy to get involved with the 11.1 beta, but will endeavour to get involved with future beta releases, and provide feedback. Cheers.

We expect to release the SDN support in upcoming releases. 

 

Please monitor announcements on our website further. 

[Digital Ridge]

Concerning that Nakvio promotes that they are 100% proxmox supported but then to find out the amount of caveats makes me think twice about the company's ability vs the marketing department.  To claim proxmox backup fully supported, would need to support SDN as they is a fully featured and even version 8.4. 

Anyone using a cluster of proxmox servers is going to be doing SDN, really is only/best way to do it. It would be like saying sorry we don't support vmware distributed switch for vmware backup...  The more I dig the more caveats I find, concerning as what's said on the tin so far has been a little far off the reality. 

Just need Nakivo to get these things working asap and keep on top of things, but I am concerned that isn't occurring with actions seen so far. 

[The Official Moderator]

On 11/25/2025 at 2:02 AM, Digital Ridge said:

Concerning that Nakvio promotes that they are 100% proxmox supported but then to find out the amount of caveats makes me think twice about the company's ability vs the marketing department.  To claim proxmox backup fully supported, would need to support SDN as they is a fully featured and even version 8.4. 

Anyone using a cluster of proxmox servers is going to be doing SDN, really is only/best way to do it. It would be like saying sorry we don't support vmware distributed switch for vmware backup...  The more I dig the more caveats I find, concerning as what's said on the tin so far has been a little far off the reality. 

Just need Nakivo to get these things working asap and keep on top of things, but I am concerned that isn't occurring with actions seen so far. 

While NAKIVO supports core Proxmox backup and recovery functionalities, we recognize that certain advanced features, such as SDN, aren't yet fully integrated.

We understand that we should communicate these limitations more clearly up front.

Regarding SDN specifically, our development team is aware of it. Although there is no firm timeline to share at this time, it's currently under active evaluation.

[Gavino]

Just to re-iterate my earlier point, even without SDN support, the current implementation is broken as it doesn't allow assigning a VLAN ID.

In the first screenshot, where the pull-down says "select a target network", what you can select there are not actually target networks. They are Linux bridges. The coders have equated ESXi Port Groups with Linux bridges, but they are not one and the same. The equivalent construct to an ESXi Port Group is actually the Proxmox SDN VNet.

Since Proxmox can use a bridge with an optional VLAN ID, at the very least we need to be able to select the VLAN ID.

The code needs to move away from the ESXi code and have:

Select Bridge [ (pulldown menu)]     (what 'Select Target Network' currently gives)
Select VLAN ID [ ...  ]   (user can type integer from 1-4093, or can be left blank)

Then when introducing SDN support, add:

[(radio box)] SDN  [Zone] [VNet]  - A check box which would grey out the above and activate a pull-down of the SDN Zones and corresponding VNets, pulled in via Proxmox API.

I think this would be straightforward to code.  I also think these details should be stored in the metadata of each VM backed up, so when you restore, it can be pre-populated. Usually you would want to put the VM back onto the same network as what it was backed up with.

[The Official Moderator]

On 12/5/2025 at 5:52 AM, Gavino said:

Just to re-iterate my earlier point, even without SDN support, the current implementation is broken as it doesn't allow assigning a VLAN ID.

In the first screenshot, where the pull-down says "select a target network", what you can select there are not actually target networks. They are Linux bridges. The coders have equated ESXi Port Groups with Linux bridges, but they are not one and the same. The equivalent construct to an ESXi Port Group is actually the Proxmox SDN VNet.

Since Proxmox can use a bridge with an optional VLAN ID, at the very least we need to be able to select the VLAN ID.

The code needs to move away from the ESXi code and have:

Select Bridge [ (pulldown menu)]     (what 'Select Target Network' currently gives)
Select VLAN ID [ ...  ]   (user can type integer from 1-4093, or can be left blank)

Then when introducing SDN support, add:

[(radio box)] SDN  [Zone] [VNet]  - A check box which would grey out the above and activate a pull-down of the SDN Zones and corresponding VNets, pulled in via Proxmox API.

I think this would be straightforward to code.  I also think these details should be stored in the metadata of each VM backed up, so when you restore, it can be pre-populated. Usually you would want to put the VM back onto the same network as what it was backed up with.

Hello @Gavino,

Thank you for your feedback. A support ticket has been created for your case (#366155), and we’re now reviewing it with our development team.

We’ll share an update with you as soon as we have more details.

[Miguel Angel]

Do we know anything about this as of today? Because we are at this exact point, and it has already been 6 months since the last post.

[The Official Moderator]

On 5/29/2026 at 1:58 PM, Miguel Angel said:

Do we know anything about this as of today? Because we are at this exact point, and it has already been 6 months since the last post.

Hi @Miguel Angel,

Thank you for your patience.
 

According to information from our product team, for now there is no ETA on this improvement.
Should you need any further information, please do not hesitate to contact NAKIVO support team at support@nakivo.com.