Bug 1328898

Reading that bug, it seems what you need is
https://bugzilla.redhat.com/show_bug.cgi?id=1043950#c10

« unfortunately the changes reveal a bug in spice-gtk that completely breaks usb-redirection. The fix is in spice-gtk git master for a while now though so its about releasing and backporting from their side. I guess I can open a bug on spice-gtk for that after backporting gnome-boxes patches for this issue.. »

Bit different from "Unix connection patches"... It would make the backporting much easier if you could point out exactly which fix this is ;)

(In reply to Christophe Fergeau from comment #2)
> Reading that bug, it seems what you need is
> https://bugzilla.redhat.com/show_bug.cgi?id=1043950#c10
> 
> « unfortunately the changes reveal a bug in spice-gtk that completely breaks
> usb-redirection. The fix is in spice-gtk git master for a while now though
> so its about releasing and backporting from their side. I guess I can open a
> bug on spice-gtk for that after backporting gnome-boxes patches for this
> issue.. »
> 
> Bit different from "Unix connection patches"... It would make the
> backporting much easier if you could point out exactly which fix this is ;)

I meant FD connection patches. i-e the patches that enable me to do this in Boxes:

https://git.gnome.org/browse/gnome-boxes/commit/?id=fb04e17a7dac24ecb14b2b0d252f025841cef075

and patches (I'm not sure which exactly but I can try to find them out for you if you need me to) in spice-gtk that fixes the breakage of usb redirection after FD connection was introduced.

(In reply to Zeeshan Ali from comment #3)

> I meant FD connection patches. i-e the patches that enable me to do this in
> Boxes:
> 
> https://git.gnome.org/browse/gnome-boxes/commit/
> ?id=fb04e17a7dac24ecb14b2b0d252f025841cef075
> 

I believe the needed API has been there since spice-gtk 0.3, RHEL has spice-gtk 0.22, so this should be plenty fine.

> and patches (I'm not sure which exactly but I can try to find them out for
> you if you need me to) in spice-gtk that fixes the breakage of usb
> redirection after FD connection was introduced.

I believe these are http://pkgs.fedoraproject.org/cgit/rpms/spice-gtk.git/commit/?id=5c1f6db

(In reply to Christophe Fergeau from comment #4)
> (In reply to Zeeshan Ali from comment #3)
> 
> > I meant FD connection patches. i-e the patches that enable me to do this in
> > Boxes:
> > 
> > https://git.gnome.org/browse/gnome-boxes/commit/
> > ?id=fb04e17a7dac24ecb14b2b0d252f025841cef075
> > 
> 
> I believe the needed API has been there since spice-gtk 0.3, RHEL has
> spice-gtk 0.22, so this should be plenty fine.

Cool.

> > and patches (I'm not sure which exactly but I can try to find them out for
> > you if you need me to) in spice-gtk that fixes the breakage of usb
> > redirection after FD connection was introduced.
> 
> I believe these are
> http://pkgs.fedoraproject.org/cgit/rpms/spice-gtk.git/commit/?id=5c1f6db

Yeah, I think so. Are they also already incluced in 7.2?

(In reply to Zeeshan Ali from comment #5)
> (In reply to Christophe Fergeau from comment #4)
> > (In reply to Zeeshan Ali from comment #3)
> > 
> > > I meant FD connection patches. i-e the patches that enable me to do this in
> > > Boxes:
> > > 
> > > https://git.gnome.org/browse/gnome-boxes/commit/
> > > ?id=fb04e17a7dac24ecb14b2b0d252f025841cef075
> > > 
> > 
> > I believe the needed API has been there since spice-gtk 0.3, RHEL has
> > spice-gtk 0.22, so this should be plenty fine.
> 
> Cool.
> 
> > > and patches (I'm not sure which exactly but I can try to find them out for
> > > you if you need me to) in spice-gtk that fixes the breakage of usb
> > > redirection after FD connection was introduced.
> > 
> > I believe these are
> > http://pkgs.fedoraproject.org/cgit/rpms/spice-gtk.git/commit/?id=5c1f6db
> 
> Yeah, I think so. Are they also already incluced in 7.2?

I cloned RHEL spice-gtk repo and found the answer: They are not yet applied (to either 7.2 or 7.3). So I guess this bug is going to be able including these patches.

(In reply to Zeeshan Ali from comment #6)
...
> I cloned RHEL spice-gtk repo and found the answer: They are not yet applied
> (to either 7.2 or 7.3). So I guess this bug is going to be able including
> these patches.

able -> about. :)

Zeeshan, so this bug is not about shipping FD connection patches but about fixing the usb redirection problem in Boxes ?

It would be easier if you explain the problem (it seems there is no problem (yet)). I really don't know what is needed to be backported and why.
Thanks

To avoid letting any local user connect to any running Boxes VMs (even ones from other users), Boxes wants to use virDomainOpenGraphicsFD rather than connecting to an IP/port. When this was done upstream, this exhibited a few bugs (audio/usb) in spice-gtk, which were fixed around spice-gtk 0.28 (forgot if this was before or after that release). That fedora git link has the 2 patches which were added to the fedora package in order to fix these bugs (I think).

(In reply to Pavel Grunt from comment #8)
> Zeeshan, so this bug is not about shipping FD connection patches but about
> fixing the usb redirection problem in Boxes ?
> 
> It would be easier if you explain the problem (it seems there is no problem
> (yet)). I really don't know what is needed to be backported and why.

It was originally filed to ensure that spice-gtk ships the FD connection patches and fixes to regressions caused by this new feature, are shipped in RHEL. I was later informed by Christophe that FD connection patches have already been shipped but not the fixes to regressions caused by these patches, so now it's about those patches. I hope that clarifies all your questions.

Shouldn't this just be a dup of #1329973, assuming gets all acks?

with 1329973 ON_QA, is this bug fixed ?

FD connection patches are shipped, closing

Hmm.. some patches might be missing cause all Boxes tests broke with latest Boxes and libvirt-glib builds. According to vbenes, the issue is that you can't connect to newly created VMs. Looking at the sample XML, I see that Boxes isn't (expectedly) setting port or listening address on spice:

    <graphics type='spice' autoport='no'>
      <image compression='off'/>
    </graphics>

He also verified this is with spice-gtk-0.31-2.el7.

logs please.. And test virt-viewer -a too.

Zeeshan,

Please open a new bug to investigate new issues, with all info/help you can provide to track the problem (Comment #16)

(In reply to Christophe Fergeau from comment #16)
> logs please.. And test virt-viewer -a too.

Yeah, vbenes has the setup so I'll ask him to test and provide details.(In reply to Victor Toso from comment #17)

> Zeeshan,
> 
> Please open a new bug to investigate new issues, with all info/help you can
> provide to track the problem (Comment #16)

I'll first want to check if it's not this bug itself. :) It could also be that I forgot some patches on Boxes side.

even virt-manager is not working  

error looks like this:
Error starting domain: internal error: process exited while connecting to monitor: utdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -device usb-ccid,id=ccid0 -drive file=/home/vbenes/.local/share/gnome-boxes/images/fed23.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=25,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:41:09:16,bus=pci.0,addr=0x3 -chardev spicevmc,id=charsmartcard0,name=smartcard -device ccid-card-passthru,chardev=charsmartcard0,id=smartcard0,bus=ccid0.0 -chardev pty,id=charserial0 -device i

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 90, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 126, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1402, in startup
    self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1035, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: process exited while connecting to monitor: utdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -device usb-ccid,id=ccid0 -drive file=/home/vbenes/.local/share/gnome-boxes/images/fed23.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=25,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:41:09:16,bus=pci.0,addr=0x3 -chardev spicevmc,id=charsmartcard0,name=smartcard -device ccid-card-passthru,chardev=charsmartcard0,id=smartcard0,bus=ccid0.0 -chardev pty,id=charserial0 -device i

Please attach libvirt logs. And try with 'virsh -c qemu:///session start xxx' and 'virt-viewer -a xxx'.

@vbenes - you can paste your log right away, it's in ${HOME}/.cache/libvirt/qemu/log/${VM_NAME}.log

Created attachment 1156724 [details]
server & client logs

Well, connection over fd works for me - I used existing domain in user session, cleared it's element entirely to just <graphics type='spice' autoport='no'/> and then I managed to connect when virt-viewer told me about --attach option. Log snippets for spice-server and virt-viewer are in the attachment. Boxes also work for me.

Note the EGL messages and getsockopt failures in client log and lack of TCP sockets in info spice output - both indicating that communication goes over unix socket:

$ virsh qemu-monitor-command --hmp fedora info spice
Server:
    migrated: false
        auth: none
    compiled: 0.12.4
  mouse-mode: client
Channels: none


$


The versions involved are (all current 7.3 + qemu from RHEV 3.6):
spice-gtk3-0.31-2.el7.x86_64
virt-viewer-2.0-7.el7.x86_64
gnome-boxes-3.14.3.1-8.el7.x86_64
spice-server-0.12.4-17.el7.x86_64
qemu-kvm-rhev-2.3.0-31.el7_2.13.x86_64
libvirt-daemon-1.3.4-1.el7.x86_64

Based on comment 22, I believe we can mark this as VERIFIED.

@zeeshan/@vbenes - your problem is something else than inclusion of patches in spice-gtk + libvirt + spice-server

@vbenes - your VM isn't starting at all and virt-manager isn't exactly helpful in telling what's going on (bug 1335617). Let's focus on qemu log in the new bug.

(In reply to David Jaša from comment #23)
> Based on comment 22, I believe we can mark this as VERIFIED.

Yes, thanks! All requested patches are in and the connection works (per comment 22).

The difference between me and Vladimír is that I'm using RHEV build of qemu 2.3 while Vlad uses stock RHEL qemu 1.5 that doesn't recognize -spice invocation without port port tls-port specification:

2016-05-16 15:09:14.071+0000: starting up libvirt version: 1.3.4, package: 1.el7 (Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>, 2016-05-03-05:10:55, x86-020.build.eng.bos.redhat.com), qemu version: 1.5.3 (qemu-kvm-1.5.3-111.el7), (...)
(...) /usr/libexec/qemu-kvm (...) -spice disable-ticketing,seamless-migration=on (...)
2016-05-16T15:09:14.112955Z qemu-kvm: neither port nor tls-port specified for spice

So @Zeeshan, please open a new bug against qemu (and probably CC Marc-André and/or Gerd). Spice-gtk, spice-server and qemu-kvm-rhev do have patches included, qemu-kvm does not.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2229.html