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