Description of problem: I think the best way to explain it would be to just show the output: ➜ ~ virt-edit -c qemu+ssh://server.local/system -d openbsd5.9 /etc/boot.conf libguestfs: error: /var/lib/libvirt/images/machines/openbsd5.9.qcow2: No such file or directory ➜ ~ Version-Release number of selected component (if applicable): libguestfs-tools-c-1.33.30-1.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1. Run virt-edit using the -c flag to specify a remote hypervisor Actual results: Above error message Expected results: Either detection of a transport suitable for remote editing and using that or an error message explicitly stating that remote disk editing isn't supported. Additional info: Whilst editing images over all remote transports mightn't be possible, it should be over SSH. Or if it isn't, an error message saying it is intentionally unsupported to stop people like me filing bug reports :)
Seems to be related to an already open ticket, adding here
This is kind of a known bug. Essentially the -c + -d options just cause virt-edit to fetch the libvirt XML from the remote server. However the paths within that XML are then processed as if they were local files. Use sshfs as described below is relatively lightweight and simple: https://rwmj.wordpress.com/2011/05/10/tip-use-libguestfs-on-vmware-esx-guests/ Or you can use any other remote filesystem or block device (NFS, SMB, NBD, iSCSI etc). There are other solutions like remoting the API using rpyc: https://rwmj.wordpress.com/2013/05/07/using-libguestfs-remotely-with-python-and-rpyc/