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