Re: Network disks and replacing qemu-block-curl|ssh with nbdkit

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/136b821f183deb0b58c571211f69179... > >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?