Re: [libvirt-users] blockcommit of domain not successfull

On Thu, Jun 13, 2019 at 16:01:18 +0200, Lentes, Bernd wrote: > > ----- On Jun 13, 2019, at 1:08 PM, Bernd Lentes > bernd.lentes(a)helmholtz-muenchen.de wrote: > > I found further information in /var/log/messages for both occurrences: > > 2019-06-01T03:05:31.620725+02:00 ha-idg-2 systemd-coredump[14253]: Core Dumping > has been disabled for process 30590 (qemu-system-x86). > 2019-06-01T03:05:31.712673+02:00 ha-idg-2 systemd-coredump[14253]: Process 30590 > (qemu-system-x86) of user 488 dumped core. > 2019-06-01T03:05:32.173272+02:00 ha-idg-2 kernel: [294682.387828] br0: port > 4(vnet2) entered disabled state > 2019-06-01T03:05:32.177111+02:00 ha-idg-2 kernel: [294682.388384] device vnet2 > left promiscuous mode > 2019-06-01T03:05:32.177122+02:00 ha-idg-2 kernel: [294682.388391] br0: port > 4(vnet2) entered disabled state > 2019-06-01T03:05:32.208916+02:00 ha-idg-2 wickedd[2954]: error retrieving tap > attribute from sysfs > 2019-06-01T03:05:41.395685+02:00 ha-idg-2 systemd-machined[2824]: Machine > qemu-31-severin terminated. > > > 2019-06-08T05:59:17.502899+02:00 ha-idg-1 systemd-coredump[31089]: Core Dumping > has been disabled for process 19489 (qemu-system-x86). > 2019-06-08T05:59:17.523050+02:00 ha-idg-1 systemd-coredump[31089]: Process 19489 > (qemu-system-x86) of user 489 dumped core. > 2019-06-08T05:59:17.650334+02:00 ha-idg-1 kernel: [999258.577132] br0: port > 9(vnet7) entered disabled state > 2019-06-08T05:59:17.650354+02:00 ha-idg-1 kernel: [999258.578103] device vnet7 > left promiscuous mode > 2019-06-08T05:59:17.650355+02:00 ha-idg-1 kernel: [999258.578108] br0: port > 9(vnet7) entered disabled state > 2019-06-08T05:59:25.983702+02:00 ha-idg-1 systemd-machined[1383]: Machine > qemu-205-severin terminated. > > Core Dumping is disabled, but nevertheless a core dump has been created ? > Where could i find it ? > Would it be useful to provide it ? So this really hints to qemu crashing. It certainly will be beneficial to collect the backtrace, but you really should report this (including the error message from the vm log file) to the qemu team. They might have even fixed it by now, so a plain update might help.