So, the disks of our VMs are stored on a GlusterFS volume.

It seems that the disk of the VM is locked, for some reason, by GlusterFS. My colleague tried to unlock the file, but it completely lock the volume. So he is currently restarting the host of the VMs and restart all the VMs.

But we think that there will be, still, a problème for the "locked" VM, we will see.

Thanks for your help,

Roland.

On Tue, Jul 5, 2016 at 4:24 PM, Daniel P. Berrange <berrange@redhat.com> wrote:

On Tue, Jul 05, 2016 at 04:20:58PM +0200, Roland Everaert wrote:
> Restarting libvirtd doesn't change the situation.
>
> But looking into the logs I see the following:
>
> - Last lines in /var/log/libvirt/libvirtd.log:
>
> 2016-07-05 13:26:42.792+0000: 24552: warning : qemuProcessKill:4419 : Timed
> out waiting after SIGKILL to process 48301
> 2016-07-05 13:26:42.792+0000: 24552: error : qemuDomainDestroyFlags:2120 :
> operation failed: failed to kill qemu process with SIGTERM
>
> - lookup for process 48301:
>
> [root@lpextvms003c ~]# ps -ef | grep 48301
> root 1114 24243 0 16:02 pts/1 00:00:00 grep 48301
> oneadmin 48301 1 4 Apr18 ? 3-08:14:18 [qemu-kvm] <defunct>

Ok, so your QEMU process has not in fact died completely, so the
libvirt state is correct.

Usual cause of a qemu going into a defunct state is a storage
failure which causes QEMU to be stuck in an uninterruptable
I/O operation wait state.

> So the process is defunct, does a 'kill -9 48301' could fix the problem
> with a restart of libvirtd?

No, as you see from the logs above, libvirt already tried to
send a SIGKILL and it had no effect. You need to figure out
what has caused QEMU to get stuck - most likely a storage I/O
problem on your machine

Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|