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: [email protected]
To contact the owner, e-mail: [email protected]

Reply via email to