On 6/19/20 7:47 AM, Richard W.M. Jones wrote:
This appears to be the cause of timeouts during the conversion step
where VMware VCenter server's Tomcat HTTPS server stops responding to
requests (or rather, responds only with 503 errors). The server later
recovers and in fact because of the retry filter the conversion
usually succeeds, but I found that we can avoid the problem by
disabling readahead.
---
v2v/nbdkit_sources.ml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Is it just a matter of readahead requesting too much data at once? Is
it time to start revisiting the idea of moving the core of the
'blocksize' filter into the server itself, in order to make it easier
for various plugins and filters to request min/max block limits, and
where the common server code then stitches together read-modify-write or
splits requests as needed to the next layer?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org