Another comment on nbdkit support

Few more things ... (1) Looking at the parameters to nbdkit in qemuNbdkitProcessBuildCommand, it might make sense to consider --exit-with-parent. What this does on Linux is it causes nbdkit to call: prctl(PR_SET_PDEATHSIG, SIGTERM); which causes the kernel to send SIGTERM to nbdkit if the parent (virtqemud, presumably?) ever goes away. This is just a belt and braces approach to ensuring that nbdkit is always cleaned up, even if libvirt dies without managing to clean up. So a couple of potential problems: (a) --exit-with-parent is only supported on a subset of platforms (currently Linux, BSD and macOS). You have to check: $ nbdkit --dump-config | grep exit exit_with_parent=yes if you might use nbdkit outside those platforms. (Using --exit-with-parent on a non-supported platform will give an error.) (b) Is virtqemud actually persistent? I'm not totally sure what happens for long-running libvirt domains if you restart libvirtd. Of course if the parent process did go away in this case then it would kill nbdkit which would be bad presumably ... (2) I'm fairly sure you'll find you need to use --selinux-label at some point. This does some SELinux/sVirt voodoo on the socket. We found that this was necessary: nbdkit -U /tmp/sock --selinux-label=system_u:object_r:svirt_socket_t:s0 ... chcon system_u:object_r:svirt_image_t:s0 /tmp/sock to allow qemu clients to connect to nbdkit when SELinux is enabled, but only some of the time (like, it works fine without this on either Fedora or RHEL, but not the other one, I forget which way round now). (3) I'm wondering if, when libvirt's own debugging is enabled, we should also add -v (verbose) and maybe even these -D flags: -v -D curl.verbose=1 # for nbdkit-curl-plugin -v -D ssh.log=2 # for nbdkit-ssh-plugin nbdkit will send debug messages to stderr or syslog (see --log=stderr|syslog option), which may or may not be useful. (4) case VIR_STORAGE_NET_PROTOCOL_NBD gives an error. Technically nbdkit does support NBD forwarding (nbdkit-nbd-plugin), but I think you're correct not to use this. It's better to have qemu connect directly using its own NBD support. (5) Now we have the infrastructure, I think a massively valuable feature would be VDDK support (nbdkit-vddk-plugin). Having libvirt being able to boot qemu VMs backed directly by VMware servers would be huge. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v