I upgraded a pool which was affected from 8.1 to 8.2 this weekend and installed the driver on one of the Hosts. Its a little early, but as you can see, there seems to be a difference in the memory usage:
Stock Driver
Stromis Driver:
One can allready see a constanty, slowly growing mem-usage in "small steps" on the Server with the stock driver, wheras the server with stormis driver seems to be stable.
Today another customer called:
He had a host (pool master) with 16GB Dom0 mem and uptime of 119 days.
Currently all my affected Systems were using megaraid_sas and iscsi and 10g intel nics.
megaraid_sas is found in @MrMike and @inaki-martinez mods too.
This is the customers lsmod:
Module Size Used by
tun 49152 0
ebtable_filter 16384 0
ebtables 36864 1 ebtable_filter
nls_utf8 16384 0
cifs 929792 0
ccm 20480 0
fscache 380928 1 cifs
iscsi_tcp 20480 16
libiscsi_tcp 28672 1 iscsi_tcp
libiscsi 61440 2 libiscsi_tcp,iscsi_tcp
scsi_transport_iscsi 110592 3 iscsi_tcp,libiscsi
bonding 176128 0
bridge 196608 1 bonding
8021q 40960 0
garp 16384 1 8021q
mrp 20480 1 8021q
stp 16384 2 bridge,garp
llc 16384 3 bridge,stp,garp
ipt_REJECT 16384 3
nf_reject_ipv4 16384 1 ipt_REJECT
xt_tcpudp 16384 8
xt_multiport 16384 1
xt_conntrack 16384 5
nf_conntrack 163840 1 xt_conntrack
nf_defrag_ipv6 20480 1 nf_conntrack
nf_defrag_ipv4 16384 1 nf_conntrack
libcrc32c 16384 1 nf_conntrack
iptable_filter 16384 1
dm_multipath 32768 0
sunrpc 413696 1
sb_edac 24576 0
intel_powerclamp 16384 0
crct10dif_pclmul 16384 0
crc32_pclmul 16384 0
ghash_clmulni_intel 16384 0
pcbc 16384 0
aesni_intel 200704 0
aes_x86_64 20480 1 aesni_intel
crypto_simd 16384 1 aesni_intel
cryptd 28672 3 crypto_simd,ghash_clmulni_intel,aesni_intel
glue_helper 16384 1 aesni_intel
dm_mod 151552 285 dm_multipath
ipmi_si 65536 0
ipmi_devintf 20480 0
intel_rapl_perf 16384 0
ipmi_msghandler 61440 2 ipmi_devintf,ipmi_si
i2c_i801 28672 0
sg 40960 0
lpc_ich 28672 0
acpi_power_meter 20480 0
ip_tables 28672 2 iptable_filter
x_tables 45056 7 ebtables,xt_conntrack,iptable_filter,xt_multiport,xt_tcpudp,ipt_REJECT,ip_tables
hid_generic 16384 0
usbhid 57344 0
hid 122880 2 usbhid,hid_generic
sd_mod 53248 9
isci 163840 0
ahci 40960 0
libsas 86016 1 isci
libahci 40960 1 ahci
scsi_transport_sas 45056 2 isci,libsas
xhci_pci 16384 0
ehci_pci 16384 0
igb 233472 0
libata 274432 3 libahci,ahci,libsas
ehci_hcd 90112 1 ehci_pci
xhci_hcd 258048 1 xhci_pci
e1000e 286720 0
megaraid_sas 167936 12
scsi_dh_rdac 16384 0
scsi_dh_hp_sw 16384 0
scsi_dh_emc 16384 0
scsi_dh_alua 20480 1
scsi_mod 253952 15 isci,scsi_dh_emc,scsi_transport_sas,sd_mod,dm_multipath,scsi_transport_iscsi,scsi_dh_alua,iscsi_tcp,libsas,libiscsi,megaraid_sas,libat a,sg,scsi_dh_rdac,scsi_dh_hp_sw
ipv6 548864 545 bridge
crc_ccitt 16384 1 ipv6
Don`t restart openvswitch, if you have active iSCSI storage attached.
@petr-bena Thanks.
I can confirm: Until now everything is stable for us, too. ( with nmi=dom0 )
@olivierlambert Since i have only production-servers with the affected hardware ATM, i cant test the 8.1 beta right now. But after relase i will try 8.1 final. Do you think there is a real chance that this error wont appear in 8.1 stock? Or should I do the same change?
Hi!
@petr-bena did you have crashes since your change nmi=dom0 ?
We have a similar problem.
There are 4 servers in different locations, two standalone, two of them in pools, all with the same hardware:
Supermicro X11SRA-RF Version: 1.02
and
Intel(R) Xeon(R) W-2145 CPU
We tried all BIOS Versions and a lot off different settings.
Two of them are runnig XCP 7.6 and have uptimes of 143 and 160 days. No Problems at all.
Two of them are running XCP 8.0 and crash regulary between 2 or 30 days, everytime with the same error.
NMI - PCI system error (SERR)
The crash is more likely to happen, if we produce high IO and/or network load on those hosts.
We suspected a hardware error, so we took one of those crashing servers to our workshop and testet it for almost two weeks with Prime95 and Memtest86 and other things that came in mind.
We were not able to produce any crash. Neither were we able to detect any errors.
We put this particular server back in production and it crashed within the first hours while we were migrating some VMs back to him. (with Storage Migration)
So i think, it has something to do with XCP-ng 8.0.
I will try the change nmi=dom0 next.
(XEN) [395218.940883]
(XEN) [395218.940886]
(XEN) [395218.940886] NMI - PCI system error (SERR)
(XEN) [395218.940889] ----[ Xen-4.11.1-7.8.xcpng8.0 x86_64 debug=n Not tainted ]----
(XEN) [395218.940889] CPU: 0
(XEN) [395218.940890] RIP: e008:[<ffff82d0802c6d38>] mwait_idle_with_hints+0xf8/0x160
(XEN) [395218.940894] RFLAGS: 0000000000000046 CONTEXT: hypervisor
(XEN) [395218.940896] rax: 0000000000000001 rbx: 000167730fc96b09 rcx: 0000000000000001
(XEN) [395218.940897] rdx: 0000000000000000 rsi: ffff83006f667ef8 rdi: ffff83006f667fff
(XEN) [395218.940898] rbp: 0000000000000000 rsp: ffff83006f667e00 r8: 0000000000000048
(XEN) [395218.940899] r9: 000530dec0dbea3e r10: 0000000000000008 r11: ffff83207cac1a68
(XEN) [395218.940900] r12: 0000000000000000 r13: 0000000000000001 r14: 0000000000000001
(XEN) [395218.940902] r15: ffff82d080573d00 cr0: 0000000080050033 cr4: 0000000000362660
(XEN) [395218.940903] cr3: 00000012c899a000 cr2: ffffe783981eb000
(XEN) [395218.940904] fsb: 0000000000000000 gsb: ffff88827bf40000 gss: 0000000000000000
(XEN) [395218.940906] ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008
(XEN) [395218.940908] Xen code around <ffff82d0802c6d38> (mwait_idle_with_hints+0xf8/0x160):
(XEN) [395218.940908] 89 f0 44 89 e9 0f 01 c9 <0f> b6 47 f5 80 a6 fd 00 00 00 fe 44 89 c1 0f 30
(XEN) [395218.940912] Xen stack trace from rsp=ffff83006f667e00:
(XEN) [395218.940913] ffff83207cac4f08 0000000000000000 ffff83207cac4e90 ffff82d080573d00
(XEN) [395218.940915] ffff82d0805baa50 ffff82d080592b20 ffff83207cac4f08 ffff82d0802ccd07
(XEN) [395218.940916] 000167730faf9015 0000000100000002 00000108000004c9 0000000000000000
(XEN) [395218.940918] 0000000000000000 ffff82d08035b43e ffff83006f7fc000 ffffffffffffffff
(XEN) [395218.940919] ffff82d08035b400 ffff82d080573d00 ffff82d0805baa50 0000000000000000
(XEN) [395218.940921] 0000000000000000 ffff82d080592b20 ffff83006f667fff ffff82d08026e505
(XEN) [395218.940922] ffff83006f7fc000 ffff83006f7fc000 ffff83006f7bf000 ffff83207cb69000
(XEN) [395218.940924] 00000000ffffffff ffff8320246cc000 ffff82d080592b20 ffff88827ae3d700
(XEN) [395218.940926] ffff88827ae3d700 0000000000000000 0000000000000000 0000000000000005
(XEN) [395218.940927] ffff88827ae3d700 0000000000000246 ffffc9004106b930 0000000000000000
(XEN) [395218.940928] 000000000001ca00 0000000000000000 ffffffff810013aa ffffffff8203c190
(XEN) [395218.940930] 0000000000000000 0000000000000001 0000010000000000 ffffffff810013aa
(XEN) [395218.940931] 000000000000e033 0000000000000246 ffffc90040113eb0 000000000000e02b
(XEN) [395218.940933] 6f5b7c2b6f667fe0 6f5b7cae00097f76 6f5b7da200000000 6f5b79516f667fe0
(XEN) [395218.940934] 0000e01000000000 ffff83006f7fc000 0000000000000000 0000000000362660
(XEN) [395218.940936] 0000000000000000 800000207caef002 0000070100000000 6f5b883e00097f00
(XEN) [395218.940938] Xen call trace:
(XEN) [395218.940939] [<ffff82d0802c6d38>] mwait_idle_with_hints+0xf8/0x160
(XEN) [395218.940942] [<ffff82d0802ccd07>] mwait-idle.c#mwait_idle+0x337/0x3d0
(XEN) [395218.940945] [<ffff82d08035b43e>] lstar_enter+0xae/0x120
(XEN) [395218.940946] [<ffff82d08035b400>] lstar_enter+0x70/0x120
(XEN) [395218.940950] [<ffff82d08026e505>] domain.c#idle_loop+0x85/0xb0
(XEN) [395218.940951]
(XEN) [395218.940952]
(XEN) [395218.940953] ****************************************
(XEN) [395218.940953] Panic on CPU 0:
(XEN) [395218.940954] FATAL TRAP: vector = 2 (nmi)
(XEN) [395218.940955] [error_code=0000] , IN INTERRUPT CONTEXT
(XEN) [395218.940955] ****************************************
(XEN) [395218.940956]
(XEN) [395218.940956] Reboot in five seconds...
(XEN) [395218.940958] Executing kexec image on cpu0
(XEN) [395218.941963] Shot down all CPUs
@olivierlambert Yes, i will update and have a look if it changes the behaviour anyhow.
"For the rest, it's hard to answer without digging more."
That`t exactly was i was looking for: Any Information where i can dig deeper?
I`m looking for logs or traces of errors or so.
It is not that i just wan`t this particular problem to be solved 
In my limited understanding of interal processes i think somehow a backup process dies and xo-server does not report or recognize this.
But shouldn`t it somehow?
@olivierlambert OK. Sorry Xen Orchestra, commit 17027 installed on Debian 10.
Just to add: I think in general it`s not something thats just happening at this version. I have seen such things happening for a few years on different systems.
Until now, i lived with it (quite well)
Just trying to explore where i can find aditional information and try to improve my understanding of whats happening under the hood.
@olivierlambert its XO, as i wrote: with Server 5.107.5 and Web 5.109.0,
Hi, i want to learn how i can troubleshoot backup job problems.
On the event of an error happening, In most cases the job status gets set to failed and i have an error message which i can then trace and resolve.
But occasionally this does not happen, like in the following example:
I have a job which runs one time in a week full backup and the other days delta.
This job started a full backup on Dec 31. 22 on 5:00 AM. It was still in the state "started" 24 hours later.
there was no visible activity anymore (no tasks, no traffic)
3VMs were backed up successfully
the timeout of this job was set to 23 hours (so it should have been killed allready?)
Because of this job beeing stuck in "Started" the following days fail with "job allready running"
On Jan 3 I restartet xo-server service and then the job was set to "interrupted" without an end time.
The delta backup on Jan 4. started as planed, but is stuck again.
I would probably be able to reconfigure the job, and it would be ok, but since this happens sometimes i would like to understand what happens.
Where i can get aditional information?
Why is it, at least after the configured timeout, not set to failed?
BTW: I am running source with Server 5.107.5 and Web 5.109.0, but i had such things happening in earlier versions too.
Hi,
in small environments with a single host, we often use https://github.com/NAUbackup/VmBackup for backup to USB Disks encrypted with LUKS.
This basically does a "xe vm-export" and works well.
We wrap this into a small shell script, that identifies the currently attached USB drive, mounts it, backups, and then unmounts it.
Everything is handled by the hosts itself.
Now i was thinking about using a XO VM fur such Tasks, the following questions came into my mind:
What would be the best way to expose the attached USB drives to a XO VM? NFS, USB Passthrough or udev SR or such?
How to configure XO for Backup Remotes that get Plugged or unplugged?
What backup Strategy would be best suited for such a Task?
I upgraded a pool which was affected from 8.1 to 8.2 this weekend and installed the driver on one of the Hosts. Its a little early, but as you can see, there seems to be a difference in the memory usage:
Stock Driver
Stromis Driver:
One can allready see a constanty, slowly growing mem-usage in "small steps" on the Server with the stock driver, wheras the server with stormis driver seems to be stable.
@ascar Maybe this helps:
https://forum.netgate.com/topic/97553/pfsense-2-3-on-xen-server/5
Also, dont forget to disable offloading.
[10:36 xs03 ~]# free -m
total used free shared buff/cache available
Mem: 11921 11322 171 151 427 175
Swap: 1023 37 986
[10:36 xs03 ~]# ps -ef | grep CROND | wc -l
1
BTW: All my affected pools never had dynamic memory.
I currently have:
top - 13:35:31 up 59 days, 17:11, 1 user, load average: 0.43, 0.36, 0.34
Tasks: 646 total, 1 running, 436 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.8 us, 1.1 sy, 0.0 ni, 97.5 id, 0.3 wa, 0.0 hi, 0.1 si, 0.2 st
KiB Mem : 12205936 total, 149152 free, 10627080 used, 1429704 buff/cache
KiB Swap: 1048572 total, 1048572 free, 0 used. 1153360 avail Mem
top - 13:35:54 up 35 days, 17:29, 1 user, load average: 0.54, 0.73, 0.77
Tasks: 489 total, 1 running, 324 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.5 us, 3.4 sy, 0.0 ni, 92.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.4 st
KiB Mem : 12207996 total, 155084 free, 9388032 used, 2664880 buff/cache
KiB Swap: 1048572 total, 1048572 free, 0 used. 2394220 avail Mem
both with:
# uname -a
Linux xs01 4.19.0+1 #1 SMP Thu Jun 11 16:18:33 CEST 2020 x86_64 x86_64 x86_64 GNU/Linux
# yum list installed | grep kernel
kernel.x86_64 4.19.19-6.0.11.1.xcpng8.1 @xcp-ng-updates
shall i test something?
Today another customer called:
He had a host (pool master) with 16GB Dom0 mem and uptime of 119 days.
Currently all my affected Systems were using megaraid_sas and iscsi and 10g intel nics.
megaraid_sas is found in @MrMike and @inaki-martinez mods too.
This is the customers lsmod:
Module Size Used by
tun 49152 0
ebtable_filter 16384 0
ebtables 36864 1 ebtable_filter
nls_utf8 16384 0
cifs 929792 0
ccm 20480 0
fscache 380928 1 cifs
iscsi_tcp 20480 16
libiscsi_tcp 28672 1 iscsi_tcp
libiscsi 61440 2 libiscsi_tcp,iscsi_tcp
scsi_transport_iscsi 110592 3 iscsi_tcp,libiscsi
bonding 176128 0
bridge 196608 1 bonding
8021q 40960 0
garp 16384 1 8021q
mrp 20480 1 8021q
stp 16384 2 bridge,garp
llc 16384 3 bridge,stp,garp
ipt_REJECT 16384 3
nf_reject_ipv4 16384 1 ipt_REJECT
xt_tcpudp 16384 8
xt_multiport 16384 1
xt_conntrack 16384 5
nf_conntrack 163840 1 xt_conntrack
nf_defrag_ipv6 20480 1 nf_conntrack
nf_defrag_ipv4 16384 1 nf_conntrack
libcrc32c 16384 1 nf_conntrack
iptable_filter 16384 1
dm_multipath 32768 0
sunrpc 413696 1
sb_edac 24576 0
intel_powerclamp 16384 0
crct10dif_pclmul 16384 0
crc32_pclmul 16384 0
ghash_clmulni_intel 16384 0
pcbc 16384 0
aesni_intel 200704 0
aes_x86_64 20480 1 aesni_intel
crypto_simd 16384 1 aesni_intel
cryptd 28672 3 crypto_simd,ghash_clmulni_intel,aesni_intel
glue_helper 16384 1 aesni_intel
dm_mod 151552 285 dm_multipath
ipmi_si 65536 0
ipmi_devintf 20480 0
intel_rapl_perf 16384 0
ipmi_msghandler 61440 2 ipmi_devintf,ipmi_si
i2c_i801 28672 0
sg 40960 0
lpc_ich 28672 0
acpi_power_meter 20480 0
ip_tables 28672 2 iptable_filter
x_tables 45056 7 ebtables,xt_conntrack,iptable_filter,xt_multiport,xt_tcpudp,ipt_REJECT,ip_tables
hid_generic 16384 0
usbhid 57344 0
hid 122880 2 usbhid,hid_generic
sd_mod 53248 9
isci 163840 0
ahci 40960 0
libsas 86016 1 isci
libahci 40960 1 ahci
scsi_transport_sas 45056 2 isci,libsas
xhci_pci 16384 0
ehci_pci 16384 0
igb 233472 0
libata 274432 3 libahci,ahci,libsas
ehci_hcd 90112 1 ehci_pci
xhci_hcd 258048 1 xhci_pci
e1000e 286720 0
megaraid_sas 167936 12
scsi_dh_rdac 16384 0
scsi_dh_hp_sw 16384 0
scsi_dh_emc 16384 0
scsi_dh_alua 20480 1
scsi_mod 253952 15 isci,scsi_dh_emc,scsi_transport_sas,sd_mod,dm_multipath,scsi_transport_iscsi,scsi_dh_alua,iscsi_tcp,libsas,libiscsi,megaraid_sas,libat a,sg,scsi_dh_rdac,scsi_dh_hp_sw
ipv6 548864 545 bridge
crc_ccitt 16384 1 ipv6