Re: [Libguestfs] Dealing with ImageIO problems
On Thu, Nov 21, 2019 at 6:24 PM Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Thu, Nov 21, 2019 at 05:50:18PM +0200, Nir Soffer wrote:
> If we want to support recoverable errors, we can define a special
> RecoverableError exception that signal the python plugin that this
> request failed, but the error is not fatal.
The problem is only the client knows if the error was recovered from.
Good point.
It's a pretty complicated problem and it seems we've got a
good enough
way to handle it from the rhv-upload-plugin now.
I agree that what we have is good enough, but it has some limitations:
- All operations are considered as fatal error in rhv-upload
- Even if client retry an operation and recovery from errors, the
plugin will fail the import
I think the issue is mixing control path and data path operations.
We do:
- on open: create disk and transfer
- on pwrite/zero/flush - translate request to imageio
- on close: finalize or cancel the transfer
While creating a disk in open matches the semantics of open() (e.g. O_CREAT),
canceling a transfer (deleting a disk) does not match the semantics of close().
The real fix for this would be:
- create a disk and transfer *before* running qemu-img and rhv-upload-plugin
(after we do the pre-checks)
- run qemu-img to transfer the data using the new rhv-upload-plugin
- if qemu failed, cancel the transfer and fail the import
- otherwise finalize the transfer and create the vm
After the recent refactoring in rhv-upload-plugin, this will be an easy change.
The relevant code is from:
https://github.com/libguestfs/virt-v2v/blob/9fca8345176d88934cf1f351633e5...
to:
https://github.com/libguestfs/virt-v2v/blob/9fca8345176d88934cf1f351633e5...
Once we have this, we can easily switch to NBD instead of imageio for better
performance, but keep both options to support older systems (4.3).
Future (4.4?) version of ovirt will support transport=HTTP/NBD argument when
creating a transfer. You will get NBD URL instead of HTTPS URL in transfer_url.
v2v will use the NBD URL directly without nbdkit/rhv-upload-plugin.
Here is the flow for transport=NBD:
- create a disk and transfer with transport=NBD
- run qemu-img convert ... overlay.qcow2 nbd://?socket=/path/to/nbd.sock
- if qemu fails, cancel the transfer and fail the import
- otherwise finalize the transfer and create the vm
We can also check if ovirt supports transport=NBD, and fallback to HTTP if not.
Later we can add TLS support so we can import from another host using
NBD TCP socket.
This requires much more work so I'm not sue it can be in 4.4.0, but
probably 4.4.z.
Nir