Thanksps -ef | grep vmname showed spice on ports 5924 and 5925. ip.host == 172.x.y.z and (tcp.port ==5924 or tcp.port == 5925) shows tens of thousands of rows.After starting a spice session to a VM on host 172.x.y.z, I used wireshark on my F18 desktop with this filter "ip.host == 172.x.y.z and (tcp.analysis.keep_alive or tcp.analysis.keep_alive_ack)" and got back no results.HiI've been talking to the group who look after the other firewall cluster and they say they can find no reason for this behaviour.
As a test, I changed the filter to just "tcp.analysis.keep_alive or tcp.analysis.keep_alive_ack" and I get many "TCP Keep-Alive" rows from other hosts
Any ideas on this?
CC--On Thu, Sep 5, 2013 at 1:46 PM, Colin Coe <colin coe gmail com> wrote:
All our RHEL guests (VMs) have the rhevm-guest-agent RPM installed and the related service 'ovirt-guest-agent' running.I run an F18 client and my colleague runs an F19 client, we both see the problem. We don't have any Fedora guests.
We have no way of running up SPICE sessions in the VLAN that our RHEV-H nodes are in, however I setup a SPICE session from between the inner and outer firewalls. This session lasted two hours before it was dropped with "TCP packet out of state: First packet isn't SYN". I'm pretty sure this isn't virt-viewers fault though as we see this from time to time when the firewall cluster changes active node.
I've asked the group that look after the other firewall to investigate.Thanks
--On Thu, Sep 5, 2013 at 9:07 AM, Marc-André Lureau <mlureau redhat com> wrote:
I am trying with current RHEL devel host&guest, connection from f19 client, over local wifi and can't reproduce so far.
----- Original Message -----
> Hmm, OK
> On the Windows locking problem, only my colleague has reported this and yes,
> the VM does have the latest RHEV Tools installed (3.2-12).
> On the timeout, this occurs for both Windows (XP,7,8,2008R2,2012) and Linux
> (RHEL5/6) VMs. All we need do to replicate the problem is to leave the SPICE
> session alone for 15 minutes or so. How should we go about debugging this?
We need to narrow the problem. Can you reproduce with a similar setup? Have you tried with f19 client? I don't think that should make any difference.
Can you try to get to a point where you don't see the problem? (for example, on local network, perhaps even on localhost)
Also, are the RHEL guest setup with RHEVM tools (I never installed those), could you try with bare VMs (without any rhevm or spice agent/drivers etc)