Hide Forgot
Description of problem: Sharing of smartcard does not work in rhel7.3 guest. Version-Release number of selected component (if applicable): client: rhel 7.3 nightly libgovirt-0.3.3-4.el7.x86_64 qemu-kvm-1.5.3-121.el7.x86_64 qemu-common-2.0.0-1.el7.6.x86_64 qemu-2.0.0-1.el7.6.x86_64 spice-glib-0.31-5.el7.x86_64 virt-viewer-2.0-11.el7.x86_64 kernel-3.10.0-493.el7.x86_64 spice-protocol-0.12.11-1.el7.noarch spice-gtk-0.31-5.el7.x86_64 qemu-kvm-common-1.5.3-121.el7.x86_64 libvirt-2.0.0-5.el7.x86_64 spice-gtk3-0.31-5.el7.x86_64 spice-vdagent-0.14.0-14.el7.x86_64 libgovirt-0.3.3-4.el7.x86_64 guest: like client except: qemu-kvm-rhev-2.3.0-31.el7_2.16.x86_64 qemu-guest-agent-2.5.0-2.el7.x86_64 spice-server-0.12.4-18.el7.x86_64 host: rhel 7.2-z rhev-m 4.0.2.7-0.1.el7ev How reproducible: always Steps to Reproduce: 1. connect smartcard reader to guest, verify that token is succesfully recognized 2. cenable smartcard sharing in rhev-m portal,get console.vv file and connect via remote-viewer 3. Actual results: no smartcard reader detected in guest Expected results: smartcard reader is succesfully shared between client and guest Additional info: * nothing about smartcard in --spice-debug log * sharing with rhel 7.3 guest libvirt VM works like a charm * usb redirection works and token is recognized * not sure if this is a qemu-kvm-rhev problem
(In reply to Radek Duda from comment #0) > Description of problem: > Sharing of smartcard does not work in rhel7.3 guest. > <snip> > > Additional info: > * nothing about smartcard in --spice-debug log > * sharing with rhel 7.3 guest libvirt VM works like a charm What do you mean here? Do you mean it works when outside of rhev-m? If that's the case, shouldn't this BZ be opened against rhev-m instead of QEMU?
Could you provide the rhevm guest/domain XML and check the presence of CCID device in the guest with lsusb? Can you also provide SPICE_DEBUG=1 log of remote-viewer? thanks
Created attachment 1196679 [details] xml of rhel7.3 in rhev-m
If I lsusb in rhev-m guest, there is no CCID device, whereas in libvirt VM guest on my host is CCID device detected: Bus 002 Device 002: ID 08e6:4433 Gemalto (was Gemplus) GemPC433-Swap I am providing spice-debug log of rhev-m guest rhel7.3, its XML configuration and also XML confiduration of libvirt guest on my host/client @adamar: yes if I do not use rhev-m and connect to libvirt guest on my host+client (managed by virt-manager), than smartcard reader + token are detected. I have also installed on my host qemu-kvm-rhev-2.6.0-22 package (instead of qemu-kvm) and it works ok as well. So it is probably a problem of rhev-m or related stuff. I am not sure which component to choose.
Created attachment 1196693 [details] xml of rhel7.3 (libvirt only)
Created attachment 1196696 [details] spice dubug log during connection to rhel7.3 rhev-m guest
Thanks a lot for the details do you see -device usb-ccid in qemu command line of rhev-m ? Could you also check if enable-smartcard=1 is in the .vv file?
yes there is no -device usb-ccid in qemu command line of problematic rhel7.3 VM. I also checked another VM (rhel7.2), where smartcard works -> the usb-ccid is in the VM configuration of this functional VM. enable-smartcard=1 is in the .vv file shall I move it to ovirt-engine? frontend.core component? I am also providing ovirt-engine.log capturing boot of rhel73_rd VM guest.
Created attachment 1196767 [details] rhel73_rd booting
Oh I missed that in the "xml of rhel7.3 in rhev-m" there is no ccid controller nor <smartcard>. So it looks like a rhevm or configuration issue for now. Please move to appropriate rhevm component
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Could you please: - attach the VDSM logs from time of starting the VM - attach the engine.log from time of starting - attach the libvirt logs from time of starting thank you
Created attachment 1200141 [details] vdsm.log while rhel73_rd VM starting
Created attachment 1200142 [details] ovirt-engine log while rhel73_rd starting
Created attachment 1200143 [details] libvirt log while rhel73_rd starting
It looks like the VM has a strange state. It seems to have the field "smartcardEnabled" set to true and at the same time the device is not there. How did you get to this VM? Has it been imported? Or created from scratch in ovirt? Or did it exist in an older system and you updated the engine? Could you please try to check the "Vm Devices" subtab for this VM and check if the smartcard is listed there? Than go to the Edit Vm, remove it, save it, than again edit it and put it back. And than check the "Vm Devices" subtab. If it will not help, if you create a new VM and enable the smartcard, does the device appear in the "Vm Devices" subtab?
VM was create from scratch in ovirt. After rechecking 'Smartcard Enabled' checkbox while the VM was not running - as you proposed, the Smartcard token was successfully detected in VM guest. Your hints helped me to find out how VM came to this state: 1. boot VM without smartcard reader device 2. Check checkbox 'Smartcard Enabled' in Edit dialog. as the result 'Smartcard Enabled' checkbox stays checked across reboots, but no smartcard device is added to the VM interface. I can add smartcard device by this checkbox only when VM is not running. So when VM is in running state, 'Smartcard Enabled' checkbox has no effect to VM devices. It applies also for windows guests. using rhev-m 4.0.4.2-0.1.el7ev now
Great, thank you for your fast feedback! Targeting 4.1 since there is a workaround.
@Marek: the smartcard is a special field which is for historical reasons both a vm_device entry and a vm_static field. While looking into this, please consider removing it from vm_static.
The bug was not addressed in time for 4.1. Postponing to 4.2
this will not get addressed for 4.2
This will not make it in a reasonable time. Please re-open if you still feel this should be fixed
I have reproduced this again with rhv4.2. If I enable smartcard while VM is running -> the device is not added immediatelly to the VM. Ok I understand this, but there should appear "Pending virtual machine changes" dialog window. What is worse that after VM is powered off and started again, no smartcard device is added to the VM even thou it's checkbox is checked. IMO this one should be certainly fixed since it could be really confusing for end-user. So reopening..
Would it be sufficient to simply disable it when the VM is up?
it's weird. probably not too hard to fix, but not too important either
(In reply to Ryan Barry from comment #27) > Would it be sufficient to simply disable it when the VM is up? This won't be consistent with general behavior of other editable console options. For example: edit USB support from 'Disabled' to 'Enabled' during VM runtime -> 'Pending virtual machine changes' dialog window appears with clear message: 'Changes that require Virtual Machine restart: usbPolicy' Ater Vm restart, there is USB device. It is good to have it like that for smartcard device too. On the other hand it is better to have no 'Smartcard' option during VM runtime than non-functional and confusing one.
This will not be addressed in a reasonable timeframe. Please re-open if it's still important.
as per #c26 reopenning
Sorry, Radek, I forgot to clear the flag before, so it got caught again :/
I reproduced again in rhv4.4. This is pretty a confusing bug. When VM is running: Edit VM -> Console -> Smartcard enabled -> OK - smartcard device is not there in qemu cmdline even if I restart VM after edit. The only solution here is to Enable smartcard when VM is down.
Lowering the priority again. It's been over 3 years without any upstream reports or tickets. Definitely low priority, and likely to be closed WONTFIX again
We didn't get to this bug for more than 2 years, and it's not being considered for the upcoming 4.4. It's unlikely that it will ever be addressed so I'm suggesting to close it. If you feel this needs to be addressed and want to work on it please remove cond nack and target accordingly.
Closing old bug. Please reopen if still relevant/you want to work on it.