Помогает откат

rpm -Uvh --force libspice-gtk3-0.30-alt1.x86_64.rpm python-module-spice-gtk-0.30-alt1.x86_64.rpm  libspice-gtk-0.30-alt1.x86_64.rpm libspice-glib-gir-0.30-alt1.x86_64.rpm libspice-glib-0.30-alt1.x86_64.rpm libspice-glib-0.30-alt1.x86_64.rpm  libspice-gtk3-gir-0.30-alt1.x86_64.rpm

А у вас включен gl для виртуалки?
http://www.spice-space.org/spice-user-manual.html#_gl_acceleration_virgl

есть такие настройки?
<video>
  <model type='virtio' heads='1'>
    <acceleration accel3d='yes'/>
  </model>
</video>
<graphics type='spice' autoport='no'>
  <gl enable='yes'/>
</graphics>

Попробуйте выключить 3D.

Оно падает на любых картах и похоже только если на хоcте, где запускаю virt-manager nvidia


Конфиг гостей  по части видео

<video>
      <model type='qxl' ram='65536' vram='65536' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>

У апстрима есть такой баг:
https://bugs.freedesktop.org/show_bug.cgi?id=95254

Да этот баг я видел но на мой не похоже.
У меня гости находятся в другом датацентре и коннект virt-manager over ssh

virt-manager схлопывается на моей рабочей станции на
NVIDIA GLX Module  361.45.11


А вот на соседний рабочей станции с
===
[    14.174] (II) LoadModule: "intel"
[    14.281] (II) Loading /usr/lib64/X11/modules/drivers/intel_drv.so
[    14.362] (II) Module intel: vendor="X.Org Foundation"
[    14.362]    compiled for 1.18.0, module version = 2.99.917
[    14.362]    Module class: X.Org Video Driver
[    14.362]    ABI class: X.Org Video Driver, version 20.0
[    14.362] (II) LoadModule: "modesetting"
===

не падает.

На проблемной станции помог только откат libspice

Такая же ошибка.

(remote-viewer:19870): GSpice-WARNING **: Warning no automount-inhibiting implementation available

(remote-viewer:19870): GSpice-CRITICAL **: egl init failed: cannot create EGL context
remote-viewer: Couldn't find current GLX or EGL context.

libspice-glib-0.32-alt1
libspice-glib-gir-0.32-alt1
libspice-gtk3-0.32-alt1
libspice-gtk3-gir-0.32-alt1
libspice-server-0.12.7-alt1
libspiro-20071029-alt2.qa2
libvirt-2.0.0-alt1
libvirt-client-2.0.0-alt1
libvirt-daemon-2.0.0-alt1
libvirt-daemon-config-network-2.0.0-alt1
libvirt-daemon-config-nwfilter-2.0.0-alt1
libvirt-daemon-driver-interface-2.0.0-alt1
libvirt-daemon-driver-network-2.0.0-alt1
libvirt-daemon-driver-nodedev-2.0.0-alt1
libvirt-daemon-driver-nwfilter-2.0.0-alt1
libvirt-daemon-driver-qemu-2.0.0-alt1
libvirt-daemon-driver-secret-2.0.0-alt1
libvirt-daemon-driver-storage-2.0.0-alt1
libvirt-glib-0.2.3-alt1
libvirt-glib-gir-0.2.3-alt1
libvirt-qemu-common-2.0.0-alt1
python-module-libvirt-2.0.0-alt1

kernel-modules-nvidia-std-def-367.35-alt1.263182.1
nvidia_glx_367.35-367.35-alt156
nvidia_glx_common-367.35-alt166
nvidia-settings-367.35-alt1
nvidia-xconfig-367.35-alt1

Решилась проблема выковыриванием из NVIDIA-Linux-x86_64-367.35-no-compat32.run
файла libGLESv1_CM_nvidia.so.367.35 и расположением его в /usr/lib64
затем ldconfig

и все заработало, почему в пакете nvidia_glx_367.35-367.35-alt156 его не оказалась ?
когда в федоре nvidia-driver-libs-364.19-2.fc24.x86_64.rpm он есть

Я в курсе; собирался сделать. Пока другие пляски были с nvidia.

P.S.
2 Shrek: По хорошему бы и в Mesa запаковать libGLESv1_CM.so.1 . Для красоты, .т.к. для решения конкретной проблемы это параллельно. Я запакую свой libGLESv1_CM.so.1, который буду переключать.

Для Mesa libGLESv1_CM.so.1 не нужен, т.ч. собирать и паковать его не к чему

(В ответ на комментарий №9)
> Для Mesa libGLESv1_CM.so.1 не нужен
Да, вот, мне тоже не совсем понятно, зачем он libspice-gtk-у. В код не смотрел, но, подозреваю, ему тоже можно оторвать.

В общем, решил запаковать, т.к. сам nvidia умеет форсировать GLESv1.
Завтра обновятся всякие *nvidia*.

(В ответ на комментарий №11)
> В общем, решил запаковать, т.к. сам nvidia умеет форсировать GLESv1.
> Завтра обновятся всякие *nvidia*.
Забыл еще nvidia_glx_common 367.35-alt168 .  Отправил сейчас на сборку.