CentOS - Dec 2014 - CentOS 7 KVM guests no longer get keystrokes after yum update

Dear all,

After "yum update" and reboot on a CentOS 7 server running kvm,
all VM guests fail to receive keyboard input. Even sending
ctrl-alt-delete from the virt-manager "Send Key" menu is
inoperative. Most guests are set up as spice + QXL, and viewed
on remote X sessions using virt-manager. Extensive browsing for a
solution has turned up only dead ends. I tried reverting to the
earlier kernel but there was no joy. Possibly I made some 
config change or installed (or removed) something that didn't
take effect until I rebooted, but searching the host's command
history has been unhelpful. Has anyone here run into this?

Connecting to a CentOS 6 guest with virt-viewer writes some
messages to the console, but what little I found in a web search 
was unhelpful. BTW, I hadn't messed with any guest keymaps,
all stock installs with en_US. 

    $ virt-viewer irc.foo.peecee3.com

    (virt-viewer:6016): GSpice-WARNING **: Warning no automount-
        inhibiting implementation available

    (virt-viewer:6016): vnc-keymap-WARNING **: Unknown keycode mapping
'(null)'.
    Please report to gtk-vnc-list at gnome.org
    including the following information:

      - Operating system
      - GDK build
      - X11 Server
      - xprop -root
      - xdpyinfo

Every attempted keystroke on the guest produces one of these 
messages:

    (virt-viewer:6016): GSpice-CRITICAL **: send_key: assertion `scancode !=
0' failed

What I think is relevant, running on the most recent kernel, all
commands run from the host:

    $ libvirtd --version
    libvirtd (libvirt) 1.2.8

    $ uname -a
    Linux mencius.peecee3.com 3.10.0-123.13.2.el7.x86_64 #1 SMP
          Thu Dec 18 14:09:13 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

    $ cat /etc/redhat-release 
    CentOS Linux release 7.0.1406 (Core) 

    $ systemctl --no-pager list-unit-files 2>&1| egrep -i
'spice|agent|virt|qxl|qemu|kvm' | grep -v '\.socket'
    machine-qemu\x2dirc.foo.peecee3.com.scope   static  
    libvirt-guests.service                      disabled
    libvirtd.service                            enabled 
    virt-who.service                            disabled
    virtlockd.service                           static  

    $ localectl status
       System Locale: LANG=en_US.UTF-8
           VC Keymap: us
          X11 Layout: us

    $ rpm -qa | egrep -i 'spice|agent|virt|qxl|qemu|kvm' | sort
    ipxe-roms-qemu-20130517-5.gitc4bce43.el7.noarch
    libgovirt-0.1.0-3.el7.x86_64
    libvirt-1.2.8-9.el7.x86_64
    libvirt-client-1.2.8-9.el7.x86_64
    libvirt-daemon-1.2.8-9.el7.x86_64
    libvirt-daemon-config-network-1.2.8-9.el7.x86_64
    libvirt-daemon-config-nwfilter-1.2.8-9.el7.x86_64
    libvirt-daemon-driver-interface-1.2.8-9.el7.x86_64
    libvirt-daemon-driver-lxc-1.2.8-9.el7.x86_64
    libvirt-daemon-driver-network-1.2.8-9.el7.x86_64
    libvirt-daemon-driver-nodedev-1.2.8-9.el7.x86_64
    libvirt-daemon-driver-nwfilter-1.2.8-9.el7.x86_64
    libvirt-daemon-driver-qemu-1.2.8-9.el7.x86_64
    libvirt-daemon-driver-secret-1.2.8-9.el7.x86_64
    libvirt-daemon-driver-storage-1.2.8-9.el7.x86_64
    libvirt-daemon-kvm-1.2.8-9.el7.x86_64
    libvirt-glib-0.1.7-3.el7.x86_64
    libvirt-python-1.2.8-5.el7.x86_64
    perl-Sys-Virt-1.1.1-5.el7.x86_64
    qemu-img-rhev-2.1.2-13.el7.x86_64
    qemu-kvm-common-rhev-2.1.2-13.el7.x86_64
    qemu-kvm-rhev-2.1.2-13.el7.x86_64
    qemu-kvm-tools-rhev-2.1.2-13.el7.x86_64
    spice-glib-0.20-8.el7.x86_64
    spice-gtk3-0.20-8.el7.x86_64
    spice-protocol-0.12.6-2.el7.noarch
    spice-server-0.12.4-5.el7_0.1.x86_64
    virt-install-1.0.1-1.el7.centos.noarch
    virt-manager-1.0.1-1.el7.centos.noarch
    virt-manager-common-1.0.1-1.el7.centos.noarch
    virt-top-1.0.8-7.el7.x86_64
    virt-viewer-0.5.7-7.el7.x86_64
    virt-what-1.13-5.el7.x86_64
    virt-who-0.8-15.el7_0.noarch

Ordinarily selinux run on the host, but I temporarily disabled
it to facilitate problem solving:

    $ getenforce
    Disabled

The qemu logs for the guests are unremarkable, and nothing much shows
up in /var/log/messages.

Thanks,
-- 
Charles Polisher