I did ponder libguestfs along the way. The big difference, at least to my understanding, is that libguestfs runs a linux kernel in its KVM guest with an associated small operating system, and then uses standard command line tools to service requests. Instar is more like a unikernel than libguestfs in the sense that instar _does_ not run a kernel as we think of it, and has no userspace. Instar is more like having the qemu-img operations performed on a service processor that just happens to be an x86 virtual core if that makes sense. I think that makes the security posture (and complexity) of the two quite different.
Okay I guess I'm not sure that's really a mark in favor of "more secure" to me. It certainly /could/ be so, and a massively smaller stack /could/ mean a smaller surface area. If it were something highly cultivated and scrutinized perhaps, but just running something on "bare metal" that was largely output that we didn't review/understand at every level doesn't really ring the bell for me. Definitely interesting and cool though :)
If you discount moving pages around in memory, which I think all inspection tools would have to do, instar does not copy the input data prior to inspection.
I'm not talking about copying pages in memory: what I meant is that glance does not ever need to store the image on disk while it's being uploaded in order to inspect it. If you back glance with swift and upload a qcow2, we never store it on disk first, inspect, and then upload to swift (aside from the import workflow that does that incidentally). We look at the stream _as_ it's being proxied to swift (or rbd, or whatever else) and we can abort the upload after you've send a few KiB, we know it's qcow2 and we know it's bad. --Dan