Re: Network disks and replacing qemu-block-curl|ssh with nbdkit

On 4/19/22 9:05 AM, Daniel P. Berrangé wrote: > On Thu, Apr 14, 2022 at 05:02:46PM -0500, Jonathon Jongsma wrote: > > As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=2016527, RHEL is > > planning to remove dependencies on the qemu-block-curl and qemu-block-ssh > > plugins from the main qemu package. This creates issues for libvirt for > > supporting network disk sources. So I've been looking into using nbdkit from > > libvirt to proxy these network disks to qemu as NBD disks. > > > > The basic idea is that libvirt will spin up an nbdkit instance for e.g. an > > https network disk source, and will provide the resulting unix socket to > > qemu as an nbd disk. This allows libvirt to continue supporting http/ftp/ssh > > disk sources regardless of whether the qemu block plugins are installed or > > not. > > > > However, there are a couple of issues and feature gaps that I've run into > > that I'd like to discuss. > > > > 1. secrets > > > > There is some code in libvirt[1] which seems to expect that it is possible > > for http(s) disk sources to have a username and password specified. However, > > I can't find any valid xml schema for specifying an http username and > > password, and my reading of the code suggests that there shouldn't be any > > way for these to be set for http(s)/ftp(s) [disk sources either since auth is > > only supported for ISCSI and RBD protocols [2]. Am I missing something? > > > > [1] https://gitlab.com/libvirt/libvirt/-/blob/6be7beb3bdb9ad611a5598dad7edfbd... > > > > [2] https://gitlab.com/libvirt/libvirt/-/blob/6be7beb3bdb9ad611a5598dad7edfbd... > > I'm unclear if this is a regression, or a long term bug. Clearly the > intention of the code is to support auth, so if it doesn't work right > now we need to fix that, regardless of adding the nbdkit support. > > I do notice we don't have any XML in tests/qemuxml2argvdata/ that > exercises auth with https, which is likely why we have this bug > lurking. Well, As far as I can tell, there is no valid XML for exercising http auth. The schema for http(s) sources does not include any <auth> element [1]. And the schema for the <auth> element [2] requires a <secret> element with a required 'type' attribute, and the only choices for 'type' are 'ceph' or 'iscsi', neither of which apply to http authentication. So it looks to me like http auth was never supported, rather than a regression. It also seems that it would require some additional schema changes to support this.

> Again, from an upstream POV #3 isn't a blocker, as long as we prefer > qemu-block-curl when available. It is upto RHEL to decide whether > #3 is a blocker for their downstream dropping of qemu-block-curl. And now I notice that we do not actually have support for 'ssh' network disks in our xml schema either [3]. The VIR_STORAGE_NET_PROTOCOL_SSH enum value was originally added with a comment that it allows using the ssh protocol in backing chains. I've also seen some commits indicating that some of the support for ssh disk sources may be related to libguestfs usage in some way. cc'ing Rich and Peter in case they can add any historical context here.