<div dir="ltr"><div><div>Hi all<br><br></div>Any thoughts on this?<br><br></div>Thanks<br><br>CC<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 12, 2013 at 11:28 AM, Colin Coe <span dir="ltr"><<a href="mailto:colin.coe@gmail.com" target="_blank">colin.coe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi<br><br></div>I've been talking to the group who look after the other firewall cluster and they say they can find no reason for this behaviour.<br>
<br></div>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. <br>
<br></div>ps -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.<br><br></div><div>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<br>
</div><div><br></div>Any ideas on this?<br><br></div>Thanks<br><br>CC<br></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Thu, Sep 5, 2013 at 1:46 PM, Colin Coe <span dir="ltr"><<a href="mailto:colin.coe@gmail.com" target="_blank">colin.coe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>All our RHEL guests (VMs) have the rhevm-guest-agent RPM installed and the related service 'ovirt-guest-agent' running.<br>
<br></div>I run an F18 client and my colleague runs an F19 client, we both see the problem. We don't have any Fedora guests. <br>
<br></div><div>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.<br>
</div><div><br>I've asked the group that look after the other firewall to investigate.<br><br></div><div>Thanks<br><br>CC<br></div><div>
<br></div><br>
</div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Thu, Sep 5, 2013 at 9:07 AM, Marc-André Lureau <span dir="ltr"><<a href="mailto:mlureau@redhat.com" target="_blank">mlureau@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
<br>
----- Original Message -----<br>
> Hmm, OK<br>
><br>
> On the Windows locking problem, only my colleague has reported this and yes,<br>
> the VM does have the latest RHEV Tools installed (3.2-12).<br>
><br>
> On the timeout, this occurs for both Windows (XP,7,8,2008R2,2012) and Linux<br>
> (RHEL5/6) VMs. All we need do to replicate the problem is to leave the SPICE<br>
> session alone for 15 minutes or so. How should we go about debugging this?<br>
<br>
</div>I am trying with current RHEL devel host&guest, connection from f19 client, over local wifi and can't reproduce so far.<br>
<br>
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.<br>
<br>
Can you try to get to a point where you don't see the problem? (for example, on local network, perhaps even on localhost)<br>
<br>
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)<br>
<br>
thanks<br>
</blockquote></div><br><br clear="all"><br></div></div><span><font color="#888888">-- <br>RHCE#805007969328369
</font></span></div>
</blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br>RHCE#805007969328369
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br>RHCE#805007969328369
</div>