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

Peter Krempa pkrempa at redhat.com
Wed Apr 20 07:21:45 UTC 2022


On Tue, Apr 19, 2022 at 22:30:51 +0100, Richard W.M. Jones wrote:
> 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?

SSH disk sources indeed never worked properly.

The existing infrastructure we have was added for the sole purpose to
allow existing libguestfs images to work. The problem why it never got
implemented was that the socket to the ssh agent was to be passed as an
environment variable to qemu so it made it very unwieldy to actually
implement it properly.

At the time I've re-wrote to use -blockdev it became necessary to be
able to parse the backing image definition at least to some extend and
thus the partial support for 'ssh' protocol was added and the support
for 'slice'-ing of the storage was added (libguestfs was accessing a
disk image inside a tar archive without actually extracting it).


More information about the libvir-list mailing list