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!