Re: [libvirt-users] libvirt 0.10 and cephx
On 09/18/2012 06:51 AM, Andrey Korolyov wrote:
Hello,
Current version adding 'auth_supported=none' at the end of disk path
and failing to do an authentication with specified cephx key:
<source protocol='rbd'
name='rbd/vmxxxxxxxxx:id=qemukvm:key=[cut]==:auth_supported=cephx'>
<host name='10.0.0.13' port='6789'/>
<host name='10.0.0.10' port='6789'/>
<host name='10.0.0.17' port='6789'/>
</source>
If you use the libvirt secret explicitly instead of passing it through
the name like that, libvirt >= 0.10 will set auth_supported=cephx if
you specify the secret, and auth_supported=none if you don't specify the
secret. For example:
secret.xml:
<secret ephemeral='no' private='no'>
<usage type='ceph'>
<name>client.qemukvm secret</name>
</usage>
</secret>
$ virsh secret-define --file secret.xml
Secret 83a0e970-a18b-5490-6fce-642f9052f832 created
$ virsh secret-set-value --secret 83a0e970-a18b-5490-6fce-642f9052f832
--base64 [key for client.qemukvm]
Then use xml with an auth element referencing that secret:
<disk type='network'>
<driver name="qemu" type="raw"/>
<source protocol='rbd' name='rbd/vmxxxxxxxxx'>
<host name='10.0.0.13' port='6789'/>
<host name='10.0.0.10' port='6789'/>
<host name='10.0.0.17' port='6789'/>
</source>
<target dev="vda" bus="virtio"/>
<auth username='qemukvm'>
<secret type='ceph'
uuid='83a0e970-a18b-5490-6fce-642f9052f832'/>
</auth>
</disk>
This secret key handling for ceph was added in libvirt 0.9.7.
Josh
results to:
0.10.1
-drive
file=rbd:rbd/vmxxxxxxxxx-YSG:id=qemukvm:key=[cut]:auth_supported=cephx:auth_supported=none:mon_host=10.0.0.13\:6789\;10.0.0.10\:6789\;10.0.0.17\:6789,if=none,id=drive-virtio-disk0,format=raw,bps_rd=80000000,bps_wr=40000000,iops_rd=400,iops_wr=200
0.9.13
-drive
file=rbd:rbd/vmxxxxxxxxx-YSG:id=qemukvm:key=[cut]:auth_supported=cephx:mon_host=10.0.0.13\:6789\;10.0.0.10\:6789\;10.0.0.17\:6789,if=none,id=drive-virtio-disk0,format=raw,bps_rd=80000000,bps_wr=40000000,iops_rd=400,iops_wr=200
In ceph-devel I have mentioned incorrectly that both strings are the
same due to incorrect grep statement, so all that needs to be fixed is
an wrong parameter at the end.
Thanks!