jiyan's problem description shows the use of ccid-card-emulated in the qemu command line in response to smartcard mode "host" passed to libvirt to indicate host Network Security Services (NSS) should be used.

Apparently ccid-card-emulated / "host" / NSS has been disabled in RHEL QEMU per https://bugzilla.redhat.com/show_bug.cgi?id=1368077

Here is the key line in the problem description showing ccid-card-emulated pased to QEMU:

2018-08-06T03:36:28.370897Z qemu-kvm: -device ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Parameter 'driver' expects pluggable device type

Seems likely ccid-card-emulated would need to be re-supported in RHEL at QEMU level or below to avoid error condition.

The device shows up in the output of "qom-list-types" even though it's disabled so libvirt thinks it's supported.

(In reply to Ján Tomko from comment #4)
> The device shows up in the output of "qom-list-types" even though it's
> disabled so libvirt thinks it's supported.

Hi all,
In qemu-kvm-rhev-2.12.0-20.el7.x86_64 & kernel-3.10.0-957.el7.x86_64, boot rhel7.6 guest with qemu command, reproduce this bug:

1.boot guest with commands:
...
-usb \
-chardev socket,id=charsmartcard0,host=127.0.0.1,port=2001,server,nowait \
-usb \
-device usb-ccid,id=ccid0 \
-device ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0 \
...

2.guest boot failed:
qemu-kvm: -device ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Parameter 'driver' expects pluggable device type

3.boot a guest without step 1 commands, guest boot successfully, and get "ccid-card-emaluted" from qmp "qmp-list-types":
{"execute":"qom-list-types"}
..
{"name": "ccid-card-emulated", "parent": "ccid-card"}
...


Regards,
Li Xiaohui

Re comment #4:
> The device shows up in the output of "qom-list-types" even though it's
> disabled so libvirt thinks it's supported.

Presence in qom-list-types implies the device model exists.  It doesn't imply it's available with -device / device_add.  As far as I can tell, the only ways to find out the latter are -device help (present means it's available) and HMP info qdm (flag no-user absent means available).

Asking for a proper QMP interface would be a fair feature request.

May I have your exact QEMU command line both for step 1 and step 2?  Should be in your libvirt logs.

Step-1: 
2019-01-30 03:22:39.362+0000: 20917: debug : virCommandRunAsync:2476 : About to run LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name guest=avocado-vt-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-avocado-vt-vm1/master-key.aes -machine pc-i440fx-rhel7.6.0,accel=kvm,usb=off,dump-guest-core=off -cpu Haswell-noTSX-IBRS -m 1024 -realtime mlock=off -smp 1,maxcpus=4,sockets=4,cores=1,threads=1 -uuid 7f604926-faf0-40c8-9ab3-dc1f2ec93da5 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=27,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -device usb-ccid,id=ccid0,bus=usb.0,port=2 -drive file=/var/lib/avocado/data/avocado-vt/images/jeos-27-x86_64.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:46:7d,bus=pci.0,addr=0x3 

-device ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0 

-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=31,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on


Step-2:
2019-01-30 03:24:40.119+0000: 20914: debug : virCommandRunAsync:2476 : About to run LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name guest=avocado-vt-vm1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-avocado-vt-vm1/master-key.aes -machine pc-i440fx-rhel7.6.0,accel=kvm,usb=off,dump-guest-core=off -cpu Haswell-noTSX-IBRS -m 1024 -realtime mlock=off -smp 1,maxcpus=4,sockets=4,cores=1,threads=1 -uuid 7f604926-faf0-40c8-9ab3-dc1f2ec93da5 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=27,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -device usb-ccid,id=ccid0,bus=usb.0,port=2 -drive file=/var/lib/avocado/data/avocado-vt/images/jeos-27-x86_64.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:46:7d,bus=pci.0,addr=0x3 

-chardev socket,id=charsmartcard0,host=127.0.0.1,port=2001,server,nowait -device ccid-card-passthru,chardev=charsmartcard0,id=smartcard0,bus=ccid0.0 

-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=31,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

This bug is about the error reported for -device ccid-card-emulated,... in comment#0 step 1:

    qemu-kvm: -device ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Parameter 'driver' expects pluggable device type

qemu-kvm reports this error because its ccid-card-emulated device model is not available with -device.  We made it unavailable there in downstream commit 9746c405955 "Enable/disable devices for RHEL 7".

The best way to disable a device model for downstream is to remove it completely from the build.  Sometimes, that's deemed too invasive, and we instead make it unavailable at the external interface.  That's what we did here.  Drawback: the device model is still listed by QMP command qom-list-types.

On closer look, removing the device model from the build is actually not particularly invasive.  Doing so would drop it from output of qom-list-types, and change the error message to

    qemu-kvm: -device ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: 'ccid-card-emulated' is not a valid device model name

Whether this error message change is much of an improvement may be debatable.  The more interesting question is whether the qom-list-types change materially improves behavior at the libvirt level.

Luyao Huang graciously tested a scratch build of qemu-kvm that has the device model removed rather than made unavailable.  The virsh error message improves to

    # virsh start vm1
    error: Failed to start domain vm1
    error: unsupported configuration: this QEMU binary lacks smartcard host mode support

Thanks!

Next step: figure out whether this is limited to <smartcard mode='host'>, or a more general issue.

We disable several devices the same way.  In theory, any of them could lead to confusion.  In practice,
ccid-card-emulated is the only case where we deceive libvirt's probe.