containers loose connection and don't regain even by recovering from working backup

D

dinis

Member
Mar 4, 2018
19
0
6
51
Hi all.
Feeling a bit desperate.
I have a couple of debian9 containers. I set up the network- everything is fine.
Then all of a sudden, both containers lost connection and are not even capable of pinging outside themselves.
The most awkward - if I try to get these containers restored from yesterdays' and previous vzdump backups / that I am 100% sure it was working), they do continue to fail.
Any idea of how I can solve this? The following images are from one of the containers.
They have firewalld, as well as apf installed but when I stop them (as well as iptables, doesn't solve).
These machines have been migrated form debian 8 - thus the eth0 - might this be the problem?

route -n results are, as follows
Code: 
Destination    Gateway     Genmask     Flags MSSWindow irtt Iface
0.0.0.0     94.23.31.254     0.0.0.0     UG     0 0    0     eth0
0.0.0.0     94.23.31.254     0.0.0.0     UG     0 0     0     eth0
94.23.31.254     0.0.0.0     255.255.255.255 UH     0 0     0     eth0


the ifconfig:
Code: 
eth0: flags=4163WP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    inet 178.33.0.67 netmask 255.255.255.255 broadcast 178.33.0.67 inet6     fe80::ff:fe2e:ce8f prefixlen 64 scopeid 0x20<link>
ether 02:00:00:2e:ce:8f txqueuelen 1000 (Ethernet) RX packets 4693 bytes 485304 (473.9 K18)
    RX errors 237 dropped 0 overruns 0 frame 237
    TX packets 16027 bytes 1329503 (1.2 MiB)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
    lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0
    inet6 ::1 prefixlen 128 scopeid Ox10<host> loop txqueuelen 1 (Local Loopback)
    RX packets 8339 bytes 588849 (575.0 Ki8) RX errors 0 dropped 0 overruns 0 frame 0 TX     packets 8339 bytes 588849 (575.0 Ki8)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


My network configs are:
Code: 
source /etc/network/interfaces.d/*
#The loopback network interface
auto lo eth0
iface lo inet loopback
iface eth0 inet static
    address 178.33.0.67
    netmask 255.255.255.255
    broadcast 178.33.0.67
    post-up route add 94.23.31.254 dev eth0
    post-up route add default gw 94.23.31.254
    pre-down route del 94.23.31.254 dev eth0
    pre-down route del default gw 94.23.31.254
    gateway 94.23.31.254

#The primary network interface
#allow-hotplug eth0
#iface eth0 inet dhcp



Thanks in advance for all the help
 
post these:

1- lxc config files: they are at /etc/pve/lxc/

2- pve host /etc/network/interfaces

jessie to stretch upgrade can end up with changes network device names - but AFAIK that effects hardware / kvm not lxc.
 
dinis said:
Destination Gateway Genmask Flags MSSWindow irtt Iface 0.0.0.0 94.23.31.254 0.0.0.0 UG 0 0 0 eth0 0.0.0.0 94.23.31.254 0.0.0.0 UG 0 0 0 eth0 94.23.31.254 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
Click to expand...
two times the gateway, that can't go good. Please post your Containerconfig.
Code: 
pct config <id>
 
fireon said:
two times the gateway, that can't go good. Please post your Containerconfig.
Code: 
pct config <id>
Click to expand...

nodes/xxx/lxc/167.conf does not exist
however, /etc/pve/nodes/xxx/qemu-server has it:


Code: 
balloon: 1500
boot: cdn
bootdisk: ide0
cores: 4
ide0: local:167/vm-167-disk-1.qcow2,size=60G
ide2: none,media=cdrom
keyboard: pt
memory: 4000
name: NAME
net0: e1000=02:00:00:2e:ce:8f,bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
smbios1: uuid=c3e1a8d0-a574-4d48-8dec-a08b6487f1c2
sockets: 2
 
Last edited:
RobFantini said:
post these:

1- lxc config files: they are at /etc/pve/lxc/

2- pve host /etc/network/interfaces

jessie to stretch upgrade can end up with changes network device names - but AFAIK that effects hardware / kvm not lxc.
Click to expand...


/etc/pve/lxc/ has no files But there are config files in /etc/pve/nodes/xxx/qemu-server.
I already posted the 167.conf in the previous answer (to fireon's question)


host interfaces:

Code: 
# for Routing
auto vmbr1
iface vmbr1 inet manual
    post-up /etc/pve/kvm-networking.sh
    bridge_ports dummy0
    bridge_stp off
    bridge_fd 0


# vmbr0: Bridging. Make sure to use only MAC adresses that were assigned to you.
auto vmbr0
iface vmbr0 inet static
    address 94.23.31.143
    netmask 255.255.255.0
    network 94.23.31.0
    broadcast 94.23.31.255
    gateway 94.23.31.254
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0

iface vmbr0 inet6 static
    address 2001:41d0:2:208f::
    netmask 64
    post-up /sbin/ip -f inet6 route add 2001:41d0:2:20ff:ff:ff:ff:ff dev vmbr0
    post-up /sbin/ip -f inet6 route add default via 2001:41d0:2:20ff:ff:ff:ff:ff
    pre-down /sbin/ip -f inet6 route del default via 2001:41d0:2:20ff:ff:ff:ff:ff
    pre-down /sbin/ip -f inet6 route del 2001:41d0:2:20ff:ff:ff:ff:ff dev vmbr0
 
Last edited:
dinis: wrote "/etc/pve/lxc/ has no files You refer to the host proxmox machine, right?"

container configuration are at /etc/pve/lxc/ on pve host.

are you using KVM or LXC [ containers] ?

PS: as Fireon said if 2 gateways then fix that. perhaps you are using KVM and the interfaces file has 2 gateway lines?
 
I believe I am using KVM -
RobFantini said:
dinis: wrote "/etc/pve/lxc/ has no files You refer to the host proxmox machine, right?"

container configuration are at /etc/pve/lxc/ on pve host.

are you using KVM or LXC [ containers] ?

PS: as Fireon said if 2 gateways then fix that. perhaps you are using KVM and the interfaces file has 2 gateway lines?
Click to expand...

where can I fix the two gateways? In the /etc/network/interfaces file? OK FIXED IT - now I only have one gateway. But problem is still there.
I think I am using KVM - but I am not sure. HOw can I get that info? OK -I confirm it is KVM - checked by creating a new VM - and that is the defult option I take.
After my first answer I found the conf files in /etc/pve/nodes/chillilime/qemu-server (I edited my first answer) - does that help ?
 
Last edited:
After fixing the interfaces, I have...
Code: 
Destination    Gateway     Genmask     Flags MSSWindow irtt Iface
0.0.0.0     94.23.31.254     0.0.0.0     UG     0 0     0     eth0
94.23.31.254     0.0.0.0     255.255.255.255 UH     0 0     0     eth0

Still, no network.
 
MIght there be an optional config in the VM that is bypassing the network configuration?
 
Is there a particular reason you are using subnet 255.255.255.255? Is it point to point connection? Double check the IP configuration you are using for that VM.
 
symmcom said:
Is there a particular reason you are using subnet 255.255.255.255? Is it point to point connection? Double check the IP configuration you are using for that VM.
Click to expand...
Hi.
I have other VM and all they work on that subnet just fine (these were instructions by the server provider - well, they were for debian 8 - not sure if they are for debian 9). Anyhow, these servers have worked a few days this config. but then snaped
 
I suggest you get the proxmox latest vestion book. there is a thread or 2 about it. get a new lxc to run. in my opinion using kvm for linux is a lot harder to get network correct then lxc. the pve interface is simple after a short while.


it is a great book. A+
 
RobFantini said:
I suggest you get the proxmox latest vestion book. there is a thread or 2 about it. get a new lxc to run. in my opinion using kvm for linux is a lot harder to get network correct then lxc. the pve interface is simple after a short while.


it is a great book. A+
Click to expand...

Hi Rob
Thanks for your input.
I have these containers and don't want to loose their contents. I already saw that I can migrate kvm to lxc however, it is quite another uncharted area for me....
Now, without network access, my data is "inside"those kvm containers.
Are you sure I am that doomed? The network was working very well. Still works very well for debian 8 VMs.
The unique thing I remember was perhaps some update of the host machine debian. and, affter that, it advised me that the kernel had changed - but I don't remember if I updated before or after this issue.
ARen't there other config files to look at? places where I
 
another idea-might this be because the host is debian 8 while the VM's are debian 9? shouldn't be but....
I would say the problem is located in the host - because the VM backups that worked perfectly now don't work when I recover them. Any one would agree that this might be a possibility?
 
RobFantini said:
I suggest you get the proxmox latest vestion book. there is a thread or 2 about it. get a new lxc to run. in my opinion using kvm for linux is a lot harder to get network correct then lxc. the pve interface is simple after a short while.


it is a great book. A+
Click to expand...
Again... I searched for how to convert kvm into lxc and got this https://pve.proxmox.com/wiki/Convert_OpenVZ_to_LXC. However my backup files are this kind: vzdump-qemu-167-2018_03_04-05_00_02.vma.gz (not tar files which maks this method not to work). any ideas?
 
Hi all.
Solved.
At the end it was not the netwrk configuration. Yesterday the IP was victim of a TCP_SYN and the provider blocked a couple of IPs on that range. They sent an email but it was blocked in the spam so I did not know my IP was off.
Sorry for disturbing. And thanks for all the help. Rob, I will look into lxc, anyhow.

All the best to all
 
You must log in or register to reply here.

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!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

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!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back