On 03/24/22 10:13, Richard W.M. Jones wrote:
> Thanks - pushed that as commit 546f3a6.
> 
> While I remember, there's another odd thing about virt-p2v that could
> be simplified if you're looking for some general clean-up work to do
> to get used to the code.
> 
> virt-p2v needs an NBD server running on the p2v machine to export the
> disks.  Originally we used qemu-nbd since that was the only choice.
> In 2017, I added support for nbdkit as an alternative to qemu-nbd.
> 
> So now we're in the situation where either server can be used (see
> virt-p2v.git/nbd.c).  For added complexity we also support both
> servers in either systemd socket activation (SA) mode or "no-SA" mode,
> so that's 4 combinations.
> 
> This is silly, we should support only one NBD server, and since
> systemd socket activation is well-supported and more flexible, we
> should just use it.
> 
> So the question is *which* NBD server to support.  That's not so much
> a technical matter since both servers can easily serve a local block
> device (always raw format).  However I do think that nbdkit might
> genuinely be the better choice here:
> 
>  - qemu-nbd links to the whole qemu block layer, nbdkit can be shipped
>    with just the plugin we need, so it should be smaller with less
>    code surface
> 
>  - nbdkit-file-plugin has a better method of not trashing the host
>    page cache
> 
>  - could use nbdkit --exit-with-parent feature (which we don't at the
>    moment)
> 
>  - nbdkit is widely available in distros these days
> 
> Also that file uses AI_ADDRCONFIG so I guess it has problems with IPv6.

Thanks, tagging this message for later.

Laszlo
_______________________________________________
Libguestfs mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/libguestfs

Reply via email to