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

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:

> >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?