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

[Richard W.M. Jones]

On Tue, Apr 19, 2022 at 11:40:49AM -0500, Jonathon Jongsma wrote:
> Well, As far as I can tell, there is no valid XML for exercising
> http auth. The schema for http(s) sources does not include any
> <auth> element [1]. And the schema for the <auth> element [2]
> requires a <secret> element with a required 'type' attribute, and
> the only choices for 'type' are 'ceph' or 'iscsi', neither of which
> apply to http authentication.
> 
> So it looks to me like http auth was never supported, rather than a
> regression. It also seems that it would require some additional
> schema changes to support this.
> 
> 
> [1] https://gitlab.com/libvirt/libvirt/-/blob/136b821f183deb0b58c571211f6917985bed3308/src/conf/schemas/domaincommon.rng#L1974
> 
> [2]https://gitlab.com/libvirt/libvirt/-/blob/136b821f183deb0b58c571211f6917985bed3308/src/conf/schemas/domaincommon.rng#L6969

As noted in my other reply, simple http auth is not practically very
useful for the kinds of sources we want to access, so if libvirt never
supported it I wouldn't bother adding that complexity now.

> >>3. blockdev-create
...

nbdkit support for creating SSH remote files is upstream now:
https://gitlab.com/nbdkit/nbdkit/-/commit/0793f30b1071753532362b2ebf9cb8156a88c3c3

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

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org