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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit _______________________________________________ Libguestfs mailing list [email protected] https://listman.redhat.com/mailman/listinfo/libguestfs
