Bug 1347830

Summary:	virt-edit on domains over remote transport attempts to edit a local path
Product:	[Community] Virtualization Tools	Reporter:	bob
Component:	libguestfs	Assignee:	Richard W.M. Jones <rjones>
Status:	NEW ---	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	ptoscano
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description bob 2016-06-17 18:41:25 UTC

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 :)

Comment 1 bob 2016-06-17 18:48:24 UTC

Seems to be related to an already open ticket, adding here

Comment 2 Richard W.M. Jones 2016-06-17 19:56:55 UTC

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/