Seems to be a bug in the template - as workaround the following helps in some cases:
Code:
echo systemctl restart network > /etc/rc.local
chmod 555 /etc/rc.localSee also https://bugzilla.proxmox.com/show_bug.cgi?id=1519
Last edited:
I found that all containers have the same issue. Proxmox rewrites the network and always sets erroneously the BOOTPROTO=none when it should not rewrite anything. Also it messes up the file /etc/resolv.conf, deleting what we put in the line DNS1=XX.X.XX.XX, and adding nameserver=192.168.0.1
Proxmox must fix this. It was designes for NATted containers, but companies need to use public IPs, and we need to be able to set it and NOT be altered by Proxmox.
Proxmox must fix this. It was designes for NATted containers, but companies need to use public IPs, and we need to be able to set it and NOT be altered by Proxmox.
Does the approach described in our documentation not work for you?
https://pve.proxmox.com/wiki/Linux_Container (section: Guest Operating System Configuration)?
https://pve.proxmox.com/wiki/Linux_Container (section: Guest Operating System Configuration)?
No, it does not. The issue is this: if you set a static IP address in the configuration, at booting, the container still has BOOTPROTO=none, when it should be BOOTPROTO=static. Since it has BOOTPROTO=none, it defaults to DHCP.
If I set "static" in the configuration, it has to migrate to the container as such.
If I set "static" in the configuration, it has to migrate to the container as such.
I think I successfully reproduced your problem.
In my case the problem was related to systemd-networkd being enabled, whereas PVE's pre-boot scripts still work with the config in /etc/sysconfig/network-scripts.
the container template has a file for eth0 in /etc/systemd/network/ - which is also where the dhcp configuration came from in my case.
disabling systemd-networkd and enabling network.service and rebooting made the container use the static ip address.
(I guess configuring systemd-networkd should also fix the problem).
The .pve-ignore file was not necessary (but did work, in preventing PVE from touching the ifcfg-eth0 file).
You can always manually set the container to unmanaged, then PVE does not touch the config at all.
Just out of curiosity - where did you get the BOOTPROTO=static information (my RedHat/Fedora/CentOS knowledge is a bit rusty, and I didn't find anything with a quick search) - in my case BOOTPROTO=none worked.
In my case the problem was related to systemd-networkd being enabled, whereas PVE's pre-boot scripts still work with the config in /etc/sysconfig/network-scripts.
the container template has a file for eth0 in /etc/systemd/network/ - which is also where the dhcp configuration came from in my case.
disabling systemd-networkd and enabling network.service and rebooting made the container use the static ip address.
(I guess configuring systemd-networkd should also fix the problem).
The .pve-ignore file was not necessary (but did work, in preventing PVE from touching the ifcfg-eth0 file).
You can always manually set the container to unmanaged, then PVE does not touch the config at all.
Just out of curiosity - where did you get the BOOTPROTO=static information (my RedHat/Fedora/CentOS knowledge is a bit rusty, and I didn't find anything with a quick search) - in my case BOOTPROTO=none worked.
BOOTPROTO=none is wrong if you are to have any IP address, the right options are static or dhcp. "none" means the interface is UP but is not communicating with the network, nor it is advertising its presence. In the Debian world there is no "none", but the equivalent is "manual". I use it all the time when my containers share the same network interface and the box has two, one for accessing the box and the second one for container access to the world. This network model is called macvlan.
As I said, if there is a BOOTPROTO=none, this is a bug in almost all scenarios. Proxmox should fix it.
As I said, if there is a BOOTPROTO=none, this is a bug in almost all scenarios. Proxmox should fix it.
We addressed the issue by configuring the network via systemd-networkd for new fedora containers (since upstream, and fedora seem to have taken this road).
pve-container > 2.0-25 contains the fix and containers created/started with it should work and configure the network as set in the container config.
The package is currently on our testing repository and tests would be much appreciated (https://pve.proxmox.com/wiki/Package_Repositories)
As for the BOOTPROTO=static - I can't find any reference to that being still supported in RHEL/CentOS >=5 (see e.g. [0], [1], [2]).
[0] https://access.redhat.com/documenta...deployment_guide/s1-networkscripts-interfaces
[1] https://github.com/cobbler/cobbler/issues/361
[2] https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-networkscripts-interfaces.html
pve-container > 2.0-25 contains the fix and containers created/started with it should work and configure the network as set in the container config.
The package is currently on our testing repository and tests would be much appreciated (https://pve.proxmox.com/wiki/Package_Repositories)
As for the BOOTPROTO=static - I can't find any reference to that being still supported in RHEL/CentOS >=5 (see e.g. [0], [1], [2]).
[0] https://access.redhat.com/documenta...deployment_guide/s1-networkscripts-interfaces
[1] https://github.com/cobbler/cobbler/issues/361
[2] https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-networkscripts-interfaces.html