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/136b821f183deb0b58c571211f6917985bed3308/src/conf/schemas/domaincommon.rng#L2150 > > > >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/8312c03dc0f688b8e99e5602658fa3e288e29156 https://github.com/libguestfs/virt-v2v/commit/10f8324bf8b97466092f9a43951a7766e0def947 https://github.com/libguestfs/virt-v2v/commit/d4f8e5a4a01b0fbbb0158d0acc11f1920a0ac4fd https://github.com/libguestfs/virt-v2v/commit/7a6f6113a25f96c813d2e73ee7e6cbd1606cfe4b 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
