[libvirt] [PATCH v3 0/5] introduce support for an embedded driver mode

[Michal Privoznik]

On 1/9/20 2:15 PM, Daniel P. Berrangé wrote:
> On Wed, Jan 08, 2020 at 05:30:23PM +0100, Michal Privoznik wrote:
>> On 12/20/19 3:16 PM, Daniel P. Berrangé wrote:
>>>
>>
>> Hm.. maybe I'm doing something wrong, but the following doesn't work for me.
>> Note, "fedora" is a VM with two disks:
>>
>>      <disk type='file' device='disk'>
>>        <driver name='qemu' type='qcow2' discard='unmap'/>
>>        <source file='/var/lib/libvirt/images/fedora.qcow2'/>
>>        <target dev='sda' bus='scsi'/>
>>        <boot order='1'/>
>>        <address type='drive' controller='0' bus='0' target='0' unit='0'/>
>>      </disk>
>>      <disk type='network' device='disk'>
>>        <driver name='qemu' type='raw'/>
>>        <source protocol='iscsi'
>> name='iqn.2017-03.com.mprivozn:server-lun-0/0'>
>>          <host name='iscsi-server.example.com' port='3260'/>
>>          <initiator>
>>            <iqn name='iqn.2017-03.com.mprivozn:client'/>
>>          </initiator>
>>          <auth username='mprivozn'>
>>            <secret type='iscsi' usage='iscsi-secret-pool'/>
>>          </auth>
>>        </source>
>>        <target dev='vda' bus='virtio'/>
>>        <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
>> function='0x0'/>
>>      </disk>
>>
>>
>> libvirt.git/_build # ./tools/virsh -c qemu:///embed?root=/tmp/embed/
>> Welcome to virsh, the virtualization interactive terminal.
>>
>> Type:  'help' for help with commands
>>         'quit' to quit
>>
>> virsh # list --all
>>   Id   Name     State
>> -------------------------
>>   -    fedora   shut off
>>
>> virsh # connect secret:///embed?root=/tmp/embed
> 
> Ok, you're opening the secret driver in embedded mode
> 
> If you *also* open the QEMU driver now, it will use
> this embedded secret driver directly.
> 
>>
>> virsh # secret-list
>>   UUID                                   Usage
>> -----------------------------------------------------------------
>>   4cf62bac-6a9f-4b9a-ba33-8c4d96b0e2e4   iscsi iscsi-secret-pool
> 
> I guess you created the XML file for this secrete previously ?
> 
> 
>> virsh # connect qemu:///embed?root=/tmp/embed
> 
> Note that this now *closes* the existing connection, so the
> embeded secret driver is now closed, and QEMU will speak to
> libvirtd (or virtsecretd) for secrets now.
> 
> Basically virsh is not a suitable tool for using the
> drivers in embedded mode since it is only capable of
> opening a single driver connection at a time.
> 
>> virsh # start fedora
>> 2020-01-08 15:37:57.294+0000: 44566: info : libvirt version: 6.0.0
>> 2020-01-08 15:37:57.294+0000: 44566: info : hostname: moe
>> 2020-01-08 15:37:57.294+0000: 44566: warning : qemuDomainDefValidate:5835 :
>> CPU topology doesn't match numa CPU count; partial NUMA mapping is obsoleted
>> and will be removed in future
>> error: Failed to start domain fedora
>> error: internal error: URI must be secret:///embed
> 
> Oh, that's odd - it seems to be trying to access the embedded
> secret driver but failing a URI sanity check. This is probably
> a result of you previously opening & then closing the embedded
> secret driver. This is not really a supported use case anyway.


Okay, since your program works, you have my:

Reviewed-by: Michal Privoznik <mprivozn at redhat.com>

for the series. However, as I suggested on the list, we should tell 
users explicitly that this feature is still under development and we may 
not be able to guarantee full backwards compatibility. May be worth 
putting somewhere into news.xml ;-)

> 
> 
>> However, running the domain (with the same disks) from regular URI is
>> impossible either:
>>
>> libvirt.git/_build # ./tools/virsh -c qemu:///system start fedora
>> error: Failed to start domain fedora
>> error: internal error: no internalFlags support
>>
>>
>> This is because if the secret is private, then we don't want to allow
>> clients getting its value. And if running the monolithic daemon, the
>> conn->secretDrive is initialized to point right to the secret driver. But
>> when using split daemons, then the connection points to the remote secret
>> driver and virtqemud is then unable to obtain the secret value.
>> Unfortunately, I don't see a way around this. I mean other than allow
>> getting the value on RPC layer.
> 
> Basically we need to establish a trust relationship between
> virtqemud and virtsecretd. I think we could relax this to mean a
> trust relationship between virtsecretd and any client which is
> running as the same user ID by default. A stronger trust relation
> could be set using the fine grained polkit ACLs, with a ACL check
> based on the API flag.

Yes, this is unrelated and pre-existing, so not a show stopper. We 
should probably track it somewhere though.

Michal