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 <mpriv...@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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
