Hi everybody. I have a problem with my CentOs VM.
My VM is running under proxmox. The server has 2 NICs and they all can access their own network (they are different, physically not connected).
My VM is EyesOfNetwork, and i want to use SNMP on 2 distincts networks.
I created 2bridges on my proxmox server.
T1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether bc:24:11:61:05:09 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.21/24 brd 192.168.1.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether bc:24:11:9a:1f:e9 brd ff:ff:ff:ff:ff:ff
hen i created the VM (EyesOfNetwork) with 2 NICs.After the installation, i checked : ip addr :
file /etc/sysconfig/network-scripts/ifcfg-eth0
TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
#BOOTPROTO="dhcp"
BOOTPROTO=none
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
#IPV6INIT="yes"
IPV6INIT="no"
#IPV6_AUTOCONF="yes"
#IPV6_DEFROUTE="yes"
#IPV6_FAILURE_FATAL="no"
#IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="eth0"
UUID="44fce560-1d5a-4dcf-a681-238b3ffa2c66"
DEVICE="eth0"
ONBOOT="yes"
IPADDR="192.168.1.21"
PREFIX="24"
GATEWAY="192.168.1.251"
#IPV6_PRIVACY="no"
DNS1="8.8.8.8"
file /etc/sysconfig/network-scripts/ifcfg-eth1
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
#BOOTPROTO=dhcp
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
#IPV6INIT=yes
#IPV6_AUTOCONF=yes
#IPV6_DEFROUTE=yes
#IPV6_FAILURE_FATAL=no
#IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eth1
UUID=38594059-4255-4249-982c-3a7b6ba157c2
DEVICE=eth1
ONBOOT=no
IPADDR=192.168.100.21
PREFIX=24
#GATEWAY=192.168.100.1
DNS1=1.1.1.1
IPV6_PRIVACY=no
As you can see eth1 (my second NIC) has no gateway. But i can't access it's network. I'm not asking to join the internet with that second nic, but why can't i access it's network ?
Thanks for helping me
2 NICS on VM Centos
Re: 2 NICS on VM Centos
You have DEFROUTE=yes in both files and it should only be in one of them - the one you want to use as the default route. I'd also not specify DNSx= in them both as they will fight over which of them updates /etc/resolv.conf. I do not think that either of those changes will affect the current problem but they should stop you from having even weirder ones later on.
With the VM booted, on the host check with brctl show and make sure that each of your VM's interfaces is listed as part of the relevant bridge - you'll need bridge-utils installed to run brctl. My next step would be to pick some random unused port and run e.g.
tcpdump port 12345 -n -nn -l -i br1
on the host and then flip to the VM and attempt to telnet 192.168.100.99 12345 to create packets destined for port 12345 on an ip address that should go via the problem interface. The VM's linux will automatically create a route for 192.168.100.0/24 since you have IPADDR=192.168.100.1 & PREFIX=24 so packets destined for any 192.168.100.x ip address should go via that interface. With tcpdump running against br1 (correct the name if necessary) on the host you should now see those packets on the host. If you don't then the problem is on the guest. If you do then the problem is on the host.
Also, use virsh domiflist $vm on the host to see the interfaces on $vm and which bridges they are attached to.
With the VM booted, on the host check with brctl show and make sure that each of your VM's interfaces is listed as part of the relevant bridge - you'll need bridge-utils installed to run brctl. My next step would be to pick some random unused port and run e.g.
tcpdump port 12345 -n -nn -l -i br1
on the host and then flip to the VM and attempt to telnet 192.168.100.99 12345 to create packets destined for port 12345 on an ip address that should go via the problem interface. The VM's linux will automatically create a route for 192.168.100.0/24 since you have IPADDR=192.168.100.1 & PREFIX=24 so packets destined for any 192.168.100.x ip address should go via that interface. With tcpdump running against br1 (correct the name if necessary) on the host you should now see those packets on the host. If you don't then the problem is on the guest. If you do then the problem is on the host.
Also, use virsh domiflist $vm on the host to see the interfaces on $vm and which bridges they are attached to.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
-
arnaud_tech
- Posts: 2
- Joined: 2023/09/01 13:21:26
Re: 2 NICS on VM Centos
Thanks to your reply.
I found the problem : on eth1 the ONBOOT was set to no.
I heard your advices and toook note in my configuration.
Thanks a lot, problem solved
I found the problem : on eth1 the ONBOOT was set to no.
I heard your advices and toook note in my configuration.
Thanks a lot, problem solved
Re: 2 NICS on VM Centos
First, the network configuration in el7 is by default via NetworkManager (NM).
The NM can and does use the older initscripts config format in /etc/sysconfig/network-scripts/ifcfg-* files (even though it does have a new format too).
Thus it is technically possible to create/edit those files directly and get NM use them.
However, an expected method is to do edits with NM tools, like nmcli or nmtui.
The rationale is that theONBOOT=no tools do store config in proper syntax (while manual edit can make typos).
Logical errors, like ONBOOT=no i.e. connection.autoconnect no, are still on user.
There is an additional way to continue the "edit files" style: config management systems.
el7 has package rhel-system-roles that includes rhel-system-roles.network Ansible role.
One does write the desired config (in YAML) for the role and Ansible can then deploy it to target machine.
https://access.redhat.com/articles/3050101 has an example.
The pros in that are that the playbook is easy to version control and backup, and Ansible can manage both initscripts and NM format files on target machines, not to mention easy adaptation to other OS (like el8, el9). The con is the investment to learn Ansible first.
Does proxmox enumerate the names "eth0" and "eth1" persistently?
Libvirt/KVM did not and devices could have swapped names on every boot of VM.
It is possible to bind a connection to device by the MAC address, rather than the name (like your config does).
That ensures that connection is on correct interface even if names are not persistent.
The NM can and does use the older initscripts config format in /etc/sysconfig/network-scripts/ifcfg-* files (even though it does have a new format too).
Thus it is technically possible to create/edit those files directly and get NM use them.
However, an expected method is to do edits with NM tools, like nmcli or nmtui.
The rationale is that theONBOOT=no tools do store config in proper syntax (while manual edit can make typos).
Logical errors, like ONBOOT=no i.e. connection.autoconnect no, are still on user.
There is an additional way to continue the "edit files" style: config management systems.
el7 has package rhel-system-roles that includes rhel-system-roles.network Ansible role.
One does write the desired config (in YAML) for the role and Ansible can then deploy it to target machine.
https://access.redhat.com/articles/3050101 has an example.
The pros in that are that the playbook is easy to version control and backup, and Ansible can manage both initscripts and NM format files on target machines, not to mention easy adaptation to other OS (like el8, el9). The con is the investment to learn Ansible first.
Does proxmox enumerate the names "eth0" and "eth1" persistently?
Libvirt/KVM did not and devices could have swapped names on every boot of VM.
It is possible to bind a connection to device by the MAC address, rather than the name (like your config does).
That ensures that connection is on correct interface even if names are not persistent.