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:
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.
As far as I can tell, we haven't ever supported it. But it is possible
that I missed something in my digging, so if anybody has any
recollection of http auth being supported in the past, please chime in.
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.
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?
Jonathon
