![](https://seccdn.libravatar.org/avatar/d85e7926e3558bc23df7a4eb6c8a7c5e.jpg?s=120&d=mm&r=g)
On 21.12.2019 07:31, Glen wrote:
So just for laughs, I ran an lsmod in both modes, and sorted and diffed them:
The "clean" guest (which appears to be stable), has these four kernel modules not present on the upgraded guest:
iptable_raw nf_conntrack_ftp nf_nat_ftp xt_CT
The "dup'ped" guest (which seems to be crashable on a large local rsync) has these modules not present on a clean install:
auth_rpcgss br_netfilter bridge
One of these two is, according to my experience, a fair candidate for your problems. I'm not a networking specialist at all, so I can't give any suggestions on how to convert the upgraded guest to a network config not requiring these modules. (Trying to get rid of br_netfilter alone may be easier, but again I'm not really knowledgeable in this area at all.) Jan
grace intel_rapl ipt_MASQUERADE llc lockd nf_conntrack_netlink nf_nat_masquerade_ipv4 nfnetlink nfs_acl nfsd overlay sb_edac stp sunrpc veth xfrm_algo xfrm_user xt_addrtype xt_nat
Both guests share these additional sysctl.conf settings:
kernel.panic = 5 vm.panic_on_oom = 2 vm.swappiness = 0 net.ipv6.conf.all.autoconf = 0 net.ipv6.conf.default.autoconf = 0 net.ipv6.conf.eth0.autoconf = 0 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_tw_reuse = 0
The dup'ped guest has these additional sysctl.conf settings:
net.ipv4.tcp_tw_recycle = 0 net.core.netdev_max_backlog=300000 net.core.somaxconn = 2048 net.core.rmem_max=67108864 net.core.wmem_max=67108864 net.ipv4.ip_local_port_range=15000 65000 net.ipv4.tcp_sack=0 net.ipv4.tcp_rmem=4096 87380 67108864 net.ipv4.tcp_wmem=4096 65536 67108864
all of which have, more or less, worked well in the past (when everything was on 42.3) and may or may not be relevant here.
I'm sorry, I feel like I'm missing something obvious here, but I can't see it. I would be grateful for any guidance or insights into this. Yes, in addition to trying to upgrade my client in place to 15.1, I could just build a new guest by hand, but that would be even more time-consuming and seems like it should not be necessary. If I might quote from the kernel, "Dazed and confused, but trying to continue" is exactly how I'm feeling here. Why could this guest be hanging? Why does an NMI bring it back? What should I do next? Anything anyone would be willing to point me to or suggest would be gratefully appreciated.
Glen
-- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org