-kernel and -initrd take a file name argument.  "Read-only drives" are
much more than files, they're block backends.  I doubt block backends
make sense with -kernel and -initrd.

We could extend -kernel and -initrd to optionally use curl.  I guess
all that'll have in common with the existing HTTP support in block
subsystem is use of curl.  I can't quite see why it needs to be
integrated into QEMU, though; the curl command exists.

I think we could make -kernel and -initd support file descriptors
defined with -add-fd.  Might be convenient for containing qemu-kvm
further.  Libvirt could set up the file descriptor as a pipeline from
curl.

Opinions?

I think having support for the full set of block backend driver is in fact very useful. For example, one common deployment method for OpenStack is to use RBD storage for both the glance image repository and the nova VM images. The kernel and initrd are stored in glance in the same way as images. Currently Nova has to pull the kernel+initrd out of glance to local storage and pass a file path to QEMU.  If the -kernel/-initrd  supported block backend drivers, then Nova could instruct QEMU to load the kernel+initrd straight from the RBD server, avoiding local storage. This would significantly simplify Nova as it would not have to deal with caching of initrd/kernel locally, and the complexity in figuring out when it is safe to purge them from the cache.  The same scenario applies to other network storage backends nova will use like glusterfs, iscsi.

Just passing a file descriptor from libvirt, or implementing curl doesn't really provide a satisfactory solution - as both options would require nova todo multiple copies of the data, rather than just having QEMU directly access the original storage backend.

This has been open for years and there does not seem to be much demand for it.