Re: [Libguestfs] Performance regression in -o rhv-upload questions

On Tue, Feb 8, 2022 at 3:27 PM Richard W.M. Jones <rjones(a)redhat.com&gt; wrote: This happens because virt-v2v try to finalize the transfer *before* closing the connections to imageio server. Current imageio release mark the a ticket as canceled, but will not remove it if the ticket has open connections from clients. If the clients are idle, the connection closes after 60 seconds, so when engine tries again to remove the ticket, the operation succeeds. Upstream version improved this flow to wait only for ongoing requests. If there are no ongoing requests the ticket is removed immediately, ignoring the open connections. The connections will be closed when the client closes the connection on when reading from the socket times out. You can test upstream version from here: https://github.com/oVirt/ovirt-imageio/actions/runs/1811058094 But if you want to be compatible with released imageio version, you must close the connections to imageio *before* finalizing the transfers. We already discussed this issue last year, when we handled the bug when vddk blocks for many minutes during block status and imageio connection is droped, and you opened a bug for this. The refactoring is not the issue, the issue is that we do not terminate the output nbdkit before finalizing. For some output we cannot do this since we want to query nbdkit for more info (e.g block status) but for rhv upload we don't have anything to do with nbkdit instance and we must close the connection before we finalize, so we should close the output right after we finish the copy. Calling flush is right, we cannot remove it. Although there is bug in nbdkit, and if flushes during close() flow even if you did not send a flush. The flow is this: - engine send request to vdsm to delete the ticket - vdsm connects to imageio control socket and send DELETE /tickets/{ticket-id} - imageio mark the ticket as canceled, so no new request can succeed and no new connection to attach to the ticket - imageio mark all ongoing requests as canceled, so if the request is in read/write loop, it will abort on the the next read/write complete - upstream: imageio waits until all ongoing operations complete - release: imageio waits until all connections are closed - if the ticket could not be removed in 60 seconds, imageio returns 409 Conflict - imageio returns 200 OK - engine retries the delete if it failed - when engine succeeds and finish other finalization tasks, the image transfer will be reported as finished. I would expect the flow to time out on virt-v2v side, since we use 60 seconds timeout, and when removing a ticket times out, it takes 60 seconds, so you should not succeed to finalize in 61 seconds. There is a bug in ovirt engine that cause this flow to succeed. Nir