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
virsh # secret-list
UUID Usage
-----------------------------------------------------------------
4cf62bac-6a9f-4b9a-ba33-8c4d96b0e2e4 iscsi iscsi-secret-pool
virsh # connect qemu:///embed?root=/tmp/embed
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
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.
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
