Description of problem: $ qemu-img create -f qcow2 -b 'json: { "file.driver":"ssh", "file.user":"root", "file.host":"avon.home.annexia.org", "file.path":"/vmfs/volumes/datastore1/Fedora 20/Fedora 20-flat.vmdk", "file.host_key_check":"no" }' /tmp/foo qemu-img file is successful, but: $ guestfish -a /tmp/foo -i [...] libvirt: invalid argument: Backing file 'json: { "file.driver":"ssh", "file.user":"root", "file.host":"avon.home.annexia.org", "file.path":"/vmfs/volumes/datastore1/Fedora 20/Fedora 20-flat.vmdk", "file.host_key_check":"no" }' of image '/tmp/foo' is missing. [code=8 domain=10] This is presumably because libvirt has trouble parsing the new qemu 2.1.0 "json:" specification. TBH I think it shouldn't even try, it should just ignore them. Certainly it shouldn't be giving an error here. Version-Release number of selected component (if applicable): libvirt-1.1.3.5-2.fc20.x86_64 How reproducible: 100% - see above.
More generically, there are two problems here: 1. Libvirt needs to catch up on the additional formats supported by upstream qemu. (This is one case where a qemu library that parses qcow2 files would be nice - if only it weren't for the fact that no such library exists in part because current qemu aborts on OOM which is inappropriate for library code) 2. Libvirt needs to have sane behavior when a backing format looks like a protocol but for which libvirt does not (yet) know the protocol. It may still be an error message, but the message should be more like 'json: protocol not yet handled by libvirt', not 'stat of file "json: ..." failed'. In other words, libvirt should NEVER attempt to stat() any protocol, known or unknown.
I'm going to clone this for RHEL 7.1 since we likely will need it fixing for virt-v2v access to ESX servers. Note I really think that if libvirt doesn't know about a protocol it should NOT error. It should assume the best.
There's already a RHEL bug tracking this which is the actual report that will generate a fix, so just duping to that *** This bug has been marked as a duplicate of bug 1134878 ***