On Tue, Apr 19, 2022 at 03:00:58PM -0500, Jonathon Jongsma wrote:
On 4/19/22 12:31 PM, Richard W.M. Jones wrote:
On Tue, Apr 19, 2022 at 11:40:49AM -0500, Jonathon Jongsma wrote:
And now I notice that we do not actually have support for 'ssh' network disks in our xml schema either [3]. The VIR_STORAGE_NET_PROTOCOL_SSH enum value was originally added with a comment that it allows using the ssh protocol in backing chains. I've also seen some commits indicating that some of the support for ssh disk sources may be related to libguestfs usage in some way. cc'ing Rich and Peter in case they can add any historical context here.
[3] https://gitlab.com/libvirt/libvirt/-/blob/136b821f183deb0b58c571211f6917985b...
Peter will remember this better, but IIRC the history was that virt-v2v used ssh protocol in backing files when accessing certain disks, ie:
- qemu-img create -b ssh:blah overlay.qcow2 - use libvirt to open overlay.qcow2
Originally libvirt didn't care about this detail, but later libvirt was changed so that it validated the backing chain. Peter added support for ssh in the backing chain.
Now actual support for protocol='ssh' (as in, the main drive, not only in the backing chain), while not currently documented, seems to be sort of working. libguestfs will try to create a protocol='ssh' drive through libvirt if you ask it:
$ guestfish --format=raw -a ssh://foo/var/tmp/newdisk run libguestfs: error: could not create appliance through libvirt. ... Original error from libvirt: internal error: qemu unexpectedly closed the monitor: 2022-04-19T17:19:47.096384Z qemu-kvm: -blockdev {"driver":"ssh","path":"/var/tmp/newdisk","server":{"host":"foo","port":"22"},"node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}: failed to authenticate using publickey authentication and the identities held by your ssh-agent [code=1 int1=-1]
If you add -vx to the guestfish command you can see the libvirt XML fragment that was used:
<disk device="disk" type="network"> <source protocol="ssh" name="/var/tmp/newdisk"> <host name="foo"/> </source> <target dev="sda" bus="scsi"/> <driver name="qemu" type="raw" cache="writeback"/> <address type="drive" controller="0" bus="0" target="0" unit="0"/> </disk>
which looks plausible. I don't understand why it doesn't work, because I've got my agent set up correctly. I wonder if it's not passing SSH_AUTH_SOCK through to session virtqemud?
Rich.
This looks like the same thing: https://bugzilla.redhat.com/show_bug.cgi?id=1140166 (and associated duplicates). It was finally closed deferred last year.
Does this mean that the ssh disk source never properly worked in libvirt?
It seems possible. That bug was closed after we switched virt-v2v to using nbdkit-ssh-plugin in these commits: https://github.com/libguestfs/virt-v2v/commit/8312c03dc0f688b8e99e5602658fa3... https://github.com/libguestfs/virt-v2v/commit/10f8324bf8b97466092f9a43951a77... https://github.com/libguestfs/virt-v2v/commit/d4f8e5a4a01b0fbbb0158d0acc11f1... https://github.com/libguestfs/virt-v2v/commit/7a6f6113a25f96c813d2e73ee7e6cb... Be nice to support ssh in libvirt if it's not too hard, since ssh/sftp is probably the most widely available remote protocol after http. Almost every server is running sshd. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top