Network disks and replacing qemu-block-curl|ssh with nbdkit
Jonathon Jongsma
jjongsma at redhat.com
Tue Apr 19 20:00:58 UTC 2022
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
More information about the libvir-list
mailing list