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

Daniel P. Berrangé berrange at redhat.com
Thu Jan 9 13:15:05 UTC 2020


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.


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


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list