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
