<div dir="ltr"><div>I have an update on the networking issue:</div><div>- After the deep dive into the logs of the firewall by customer's security team, it turns out that even though there were some disconnections, the time-stamps do not match. <br></div><div> This means that we got the disconnected by something else (ESXi or conversion host perhaps)<br></div><div>- As we mentioned in the chat briefly, there could be general keep-alive issues on both RHEL (conversion host) and ESXi side. <br></div><div> We changed the keep-alive settings in RHEL, but could not find the equvalent in VMware as of yet. <br></div><div>- I found on a few spots that there are some vddk (vixDiskLib.nfc*) settings which can configure NFC keep-alives and timeouts, but I do not understand it deeply enough to see if anything would help.</div><div><br></div><div>Whatever may be the cause, a retry filter would most likely solve the problem.<br></div><div></div><div><br></div><div>Since we are fairly certain that we would encounter another failure with VDDK how the situation stands now, we are trying SSH transport to see how that will go. <br></div><div><br></div><div>Cheers,</div><div></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><p style="margin:0px;padding:0px"><b style="font-family:arial,helvetica,sans-serif;font-size:small"><font color="#cc0000"><span style="margin:0px;padding:0px">Nenad Perić</span><span style="margin:0px;padding:0px"></span></font></b><br></p><p style="font-size:small;color:rgb(0,0,0);margin:0px;padding:0px"><span style="font-family:arial,helvetica,sans-serif;font-size:x-small">PRINCIPAL SOFTWARE ENGINEER</span><font size="1" face="arial, helvetica, sans-serif"><br style="margin:0px;padding:0px"></font></p><p style="font-size:small;margin:0px;padding:0px"><font size="1" face="arial, helvetica, sans-serif" color="#000000">Red Hat - Migration Engineering</font></p><p style="margin:0px;padding:0px"><font size="1" face="arial, helvetica, sans-serif"><span style="margin:0px;padding:0px"><span style="margin:0px;padding:0px"><a href="mailto:nenad@redhat.com" target="_blank"><font color="#0b5394">nenad@redhat.com </font></a></span></span><span style="margin:0px;padding:0px"></span></font></p><p style="margin:0px;padding:0px"><span style="margin:0px;padding:0px"><font size="1" face="arial, helvetica, sans-serif"><a href="http://redhat.com" style="color:rgb(0,0,0)" target="_blank"><img src="https://www.google.com/a/cpanel/redhat.com/images/logo.gif?service=google_gsuite" width="96" height="39"></a><font color="#000000"> </font><span style="margin:0px;padding:0px"></span></font></span></p></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 19, 2019 at 11:50 AM Richard W.M. Jones <<a href="mailto:rjones@redhat.com">rjones@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Sep 18, 2019 at 01:59:01PM +0100, Richard W.M. Jones wrote:<br>
> We have a running problem with the nbdkit VDDK plugin where the VDDK<br>
> side apparently disconnects or the network connection is interrupted.<br>
> During a virt-v2v conversion this causes the entire operation to fail,<br>
> and since v2v conversions take many hours that's not a happy outcome.<br>
> <br>
> (Aside: I should say that we see many cases where it's claimed that<br>
> the connection was dropped, but often when we examine them in detail<br>
> the cause is something else.  But it seems like this disconnection<br>
> thing does happen sometimes.)<br>
<br>
It turns out in the customer case that led us to talk about this, a<br>
Checkpoint firewall was forcing the VDDK control connection to be<br>
closed after an idle period.  (The VDDK connection as a whole was not<br>
actually idle because data was being copied over the separate data<br>
port, but the firewall did not associate the two ports).  I believe<br>
nbdkit-retry-filter would have helped in this case because reopening<br>
the VDDK connection will reestablish the control/metadata connection,<br>
and therefore I am looking at an implementation now.<br>
<br>
Rich.<br>
<br>
-- <br>
Richard Jones, Virtualization Group, Red Hat <a href="http://people.redhat.com/~rjones" rel="noreferrer" target="_blank">http://people.redhat.com/~rjones</a><br>
Read my programming and virtualization blog: <a href="http://rwmj.wordpress.com" rel="noreferrer" target="_blank">http://rwmj.wordpress.com</a><br>
virt-top is 'top' for virtual machines.  Tiny program with many<br>
powerful monitoring features, net stats, disk stats, logging, etc.<br>
<a href="http://people.redhat.com/~rjones/virt-top" rel="noreferrer" target="_blank">http://people.redhat.com/~rjones/virt-top</a><br>
</blockquote></div>