Fedora 27 container has a problem

falves1

Well-Known Member
Jan 11, 2009
99
3
48
I created a Fedora 27 container with a public IP address, but the resulting IP inside the container is DHCP. I am at a loss as how to fix this, since the configuration is correct. Is there an override to the automatic overwriting of network files?
 

Attachments

  • proxmox-error.png
    proxmox-error.png
    42.9 KB · Views: 10
I created a Fedora 27 container with a public IP address, but the resulting IP inside the container is DHCP. I am at a loss as how to fix this, since the configuration is correct. Is there an override to the automatic overwriting of network files?

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.local

See 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.
 
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.
 
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.
 
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.
 
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
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!