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

[Richard W.M. Jones]

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