On 21/01, Nir Soffer wrote: > On Thu, Jan 21, 2021 at 8:50 AM Konstantin Shalygin <k0...@k0ste.ru> wrote: > > > > I understood, more than the code that works with qemu already exists for > > openstack integration > > We have code on vdsm and engine to support librbd, but using in cinderlib > based volume is not a trivial change. > > On engine side, this means changing the flow, so instead of attaching > a device to a host, engine will configure the xml with network disk, using > the rbd url, same way as old cinder support was using. > > To make this work, engine needs to configure the ceph authentication > secrets on all hosts in the DC. We have code to do this for old cinder storage > doman, but it is not used for new cinderlib setup. I'm not sure how easy is to > use the same mechanism for cinderlib.
Hi, All the data is in the connection info (including the keyring), so it should be possible to implement. > > Generally, we don't want to spend time on special code for ceph, and prefer > to outsource this to os brick and the kernel, so we have a uniform way to > use volumes. But if the special code gives important benefits, we can > consider it. > I think think that's reasonable. Having less code to worry about and making the project's code base more readable and maintainable is a considerable benefit that should not be underestimated. > I think openshift virtualization is using the same solution (kernel based rbd) > for ceph. An important requirement for us is having an easy way to migrate > vms from ovirt to openshift virtuations. Using the same ceph configuration > can make this migration easier. > The Ceph CSI plugin seems to have the possibility of using krbd and rbd-nbd [1], but that's something we can also achieve in oVirt by adding back the rbd-nbd support in cinderlib without changes to oVirt. Cheers, Gorka. [1]: https://github.com/ceph/ceph-csi/blob/04644c1d5896b493d6aaf9ab66f2302cf67a2ee3/internal/rbd/rbd_attach.go#L35-L41 > I'm also not sure about the future of librbd support in qemu. I know that > qemu folks also want to get rid of such code. For example libgfapi > (Glsuter native driver) is not maintained and likely to be removed soon. > > If this feature is important to you, please open RFE for this, and explain why > it is needed. > > We can consider it for future 4.4.z release. > > Adding some storage and qemu folks to get more info on this. > > Nir > _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/SUXZT47HWHALTYOUF67ALJTMK653SNBO/
