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.
I have a rough patch series covering all of this, with (thus far) the
cumulative diffstat
Makefile.am | 2 -
contrib/aux-scripts/do-build.sh | 3 -
contrib/patches/0002-RHEL-5-ONLY-QEMU-NBD-1.4-HAS-NO-f-OPTION.patch | 34 --
conversion.c | 13 +-
dependencies.m4 | 2 -
docs/p2v-building.pod | 9 +-
main.c | 7 +-
nbd.c | 474
+++-----------------
p2v.h | 4 +-
test-virt-p2v-nbdkit.sh | 6 +-
test-virt-p2v-scp.sh | 2 +-
test-virt-p2v-ssh.sh | 4 +-
test-virt-p2v.sh | 56 ---
virt-p2v.pod | 49 +-
14 files changed, 74 insertions(+), 591 deletions(-)
I intend to clean up the patches (re-read the commit messages, check
that each patch builds etc -- in fact I've just noticed yet another
opportunity for simplification), but even then, I think I'll only post
the first version as an RFC. The changes are pretty intrusive, I could
have easily missed something, and I'm quite certain that I cannot test
this series with sufficient coverage.
Thanks
Laszlo