Anyway to support interfaces.d/*

[EugenMayer]

I am using chef to configure my host network and bridges, but as to due best practices it happens to interfaces.d/eth0 .. interfaces.d/vmbr0 and so on, while /e/n/interfaces is just an include like

source /etc/network/interfaces.d/*

doing that leads to issues with proxmox, which will not offer me any bridges/interfaces for my KVM machines.

Is there any way to let proxmox read interfaces.d ?

 

[fabian]

I am using chef to configure my host network and bridges, but as to due best practices it happens to interfaces.d/eth0 .. interfaces.d/vmbr0 and so on, while /e/n/interfaces is just an include like

source /etc/network/interfaces.d/*

doing that leads to issues with proxmox, which will not offer me any bridges/interfaces for my KVM machines.

Is there any way to let proxmox read interfaces.d ?

yes - somebody would need to write the patches to support those files.

since we not only need to parse them, but also write them, this is not as trivial as it sounds - especially since the whole /etc/network/interfaces handling is rather under-documented in Debian itself IMHO, so things like ordering, handling of errors and duplicates need to be taken into consideration.

IMHO I'd rather see support for systemd-networkd - but that is probably a different story

 

[EugenMayer]

Thank you Fabian, so yet no "build in" way i guess, right

 

[Dura]

This is really annoying because it's undocumented and it makes us waste several hours and here is the only place to read about it...

If it never gets fixed, then you should add something directly in /interfaces to warn us to not use interfaces.d/ or something of this kind

 

[jHGbc]

So this stuff caused me to waste like 6 hours of debugging ... I am not very happy about Proxmox at the moment. Where can I send in a patch to get rid of this stuff?

 

[oguz]

Where can I send in a patch

See https://pve.proxmox.com/wiki/Developer_Documentation

 

[jHGbc]

Thanks we are checking out a solution and a staff member will send a patch as we worked something out.

 

[ruepelralf]

Any updates on this Topic?

Thanks we are checking out a solution and a staff member will send a patch as we worked something out.

Did you guys find a solution? We are having the same problem!

 

[syfy323]

Any updates on this Topic?

Did you guys find a solution? We are having the same problem!

Same here...

since we not only need to parse them, but also write them, this is not as trivial as it sounds - especially since the whole /etc/network/interfaces handling is rather under-documented in Debian itself IMHO, so things like ordering, handling of errors and duplicates need to be taken into consideration.

Why not implement reading them first? As the OP stated, they deploy the network config using interfaces.d files. I do the same with other tools.
I don't like the approach of removing support for an OS standard feature from the Proxmox GUI (forcefully, as VMs can't use defined bridges).
It would be sufficient to block access to the GUI's network setup when an unsupported configuration has been detected but display the bridges in VM setup.

For example: I have a highly customized OVS setup, automated by some scripts. I will never use the Proxmox GUI for network setup but atm, I am unable to use Proxmox at all. Very sad :-(

RFC

 

[fabian]

Same here...



Why not implement reading them first? As the OP stated, they deploy the network config using interfaces.d files. I do the same with other tools.
I don't like the approach of removing support for an OS standard feature from the Proxmox GUI (forcefully, as VMs can't use defined bridges).
It would be sufficient to block access to the GUI's network setup when an unsupported configuration has been detected but display the bridges in VM setup.

For example: I have a highly customized OVS setup, automated by some scripts. I will never use the Proxmox GUI for network setup but atm, I am unable to use Proxmox at all. Very sad :-(

RFC

you are not unable to use Proxmox at all - you just can't use some of the GUI features/autocompletion? you can use arbitrary bridges that PVE does not manage/know about at all, and reference them in the guest configs all you want..

 

[syfy323]

you are not unable to use Proxmox at all - you just can't use some of the GUI features/autocompletion? you can use arbitrary bridges that PVE does not manage/know about at all, and reference them in the guest configs all you want..

Either I do it wrong or it does not work. I have several interfaces, some OVS some LB defined using interfaces.d files from my CMDB. They work fine.
If I try to add a VM, I am unable to choose any bridge - the list is empty and has a red border.

 

[fabian]

Either I do it wrong or it does not work. I have several interfaces, some OVS some LB defined using interfaces.d files from my CMDB. They work fine.
If I try to add a VM, I am unable to choose any bridge - the list is empty and has a red border.

like I said - you just can't use the GUI, since the GUI ask PVE first which bridges it knows. the backend doesn't care - you can put in any bridge via 'qm/pct set', the REST API, or directly in the config file. we could probably also allow free-form entry in those fields in the GUI - @dcsapak ?

 

[syfy323]

like I said - you just can't use the GUI, since the GUI ask PVE first which bridges it knows. the backend doesn't care - you can put in any bridge via 'qm/pct set', the REST API, or directly in the config file. we could probably also allow free-form entry in those fields in the GUI - @dcsapak ?

The whole point for me and proxmox is the GUI. If I would like to add / edit VMs the hard way, I would use virsh / libvirtd
What I have in mind is: Why MUST proxmox configure the network itself? Why not just disable that page, if such an unsupported configuration (which works) has been found? The admin most likely knows what he does and will not use the GUI to change anything.

The reason why I use Proxmox, is that non-experts are able to manage their VMs. On the other side, as an expert for linux, I want to automate as much as possible. I've now built a solution to move all interfaces.d files into the interfaces file using the CMDB, which I will test now.

 

[t.lamprecht]

we could probably also allow free-form entry in those fields in the GUI - @dcsapak ?

Could sure, as VMs/CTs just die when nothing is (i.e., no-existent bridge entered by mistak) there I'd guess that the behaviour wouldn't regress to bad from an UX standpoint, not ideal but a trad-off one can accept.

But, what permissions do you require for that? As you now then can add (probe?) for every bridge on the system more easily?
If that's possible over the API already that would be one thing to restrict, IMO.

 

[syfy323]

I've now merged all interfaces into the main file. The server boots fine, all interfaces are up.
The Proxmox GUI still does not list any interface and the assistant does not show them either.

My config looks like this:
https://paste.fedoraproject.org/paste/m10bUuSnNb-mKpXLX~k-tg

Might be an issue with whitespaces or new lines.

 

[oguz]

I've now merged all interfaces into the main file. The server boots fine, all interfaces are up.
The Proxmox GUI still does not list any interface and the assistant does not show them either.

My config looks like this:
https://paste.fedoraproject.org/paste/m10bUuSnNb-mKpXLX~k-tg

Might be an issue with whitespaces or new lines.

what about the permissions on the interfaces file? i remember one user had a similar issue (red border and no selection possible) when they backed up and restored the interfaces file, but the permissions didn't match. it needs to be -rw-r--r-- (644)

 

[fabian]

Could sure, as VMs/CTs just die when nothing is (i.e., no-existent bridge entered by mistak) there I'd guess that the behaviour wouldn't regress to bad from an UX standpoint, not ideal but a trad-off one can accept.

But, what permissions do you require for that? As you now then can add (probe?) for every bridge on the system more easily?
If that's possible over the API already that would be one thing to restrict, IMO.

true. but that enumeration is already possible via the API maybe one day we get a '/network/...' ACL path..

 

[syfy323]

what about the permissions on the interfaces file? i remember one user had a similar issue (red border and no selection possible) when they backed up and restored the interfaces file, but the permissions didn't match. it needs to be -rw-r--r-- (644)

You did it!
I've implemented a fix to remove the unneeded newlines. I've also applied your chmod fix. Works so far. I just need to adjust the naming of the OVS bridges.