Currently integration don't need nbd or krbd. Just qemu process.
k Sent from my iPhone > On 28 Dec 2020, at 15:28, Benny Zlotnik <[email protected]> wrote: > > On Tue, Dec 22, 2020 at 6:33 PM Konstantin Shalygin <[email protected]> wrote: >> >> Sandro, FYI we are not against cinderlib integration, more than we are >> upgrade 4.3 to 4.4 due movement to cinderlib. >> >> But (!) current Managed Storage Block realization support only krbd (kernel >> RBD) driver - it's also not a option, because kernel client is always >> lagging behind librbd, and every update\bugfix we should reboot whole host >> instead simple migration of all VMs and then migrate it back. Also with krbd >> host will be use kernel page cache, and will not be unmounted if VM will >> crash (qemu with librbd is one userland process). >> > > There was rbd-nbd support at some point in cinderlib[1] which > addresses your concerns, but it was removed because of some issues > > +Gorka, are there any plans to pick it up again? > > [1] > https://github.com/Akrog/cinderlib/commit/a09a7e12fe685d747ed390a59cd42d0acd1399e4 > > > >> So for me current situation look like this: >> >> 1. We update deprecated OpenStack code? Why, Its for delete?.. Nevermind, >> just update this code... >> >> 2. Hmm... auth tests doesn't work, to pass test just disable any OpenStack >> project_id related things... and... Done... >> >> 3. I don't care how current cinder + qemu code works, just write new one for >> linux kernel, it's optimal to use userland apps, just add wrappers (no, it's >> not); >> >> 4. Current Cinder integration require zero configuration on oVirt hosts. >> It's lazy, why oVirt administrator do nothing? just write manual how-to >> install packages - oVirt administrators love anything except "reinstall" >> from engine (no, it's not); >> >> 5. We broke old code. New features is "Cinderlib is a Technology Preview >> feature only. Technology Preview features are not supported with Red Hat >> production service level agreements (SLAs), might not be functionally >> complete, and Red Hat does not recommend to use them for production". >> >> 6. Oh, we broke old code. Let's deprecate them and close PRODUCTION issues >> (we didn't see anything). >> >> >> And again, we are not hate new cinderlib integration. We just want that new >> technology don't break all PRODUCTION clustes. Almost two years ago I write >> on this issue https://bugzilla.redhat.com/show_bug.cgi?id=1539837#c6 about >> "before deprecate, let's help to migrate". For now I see that oVirt totally >> will disable QEMU RBD support and want to use kernel RBD module + python >> os-brick + userland mappers + shell wrappers. >> >> >> Thanks, I hope I am writing this for a reason and it will help build bridges >> between the community and the developers. We have been with oVirt for almost >> 10 years and now it is a crossroads towards a different virtualization >> manager. >> >> k >> >> >> So I see only regressions for now, hope we'll found some code owner who can >> catch this oVirt 4.4 only bugs. >> > > I looked at the bugs and I see you've already identified the problem > and have patches attached, if you can submit the patches and verify > them perhaps we can merge the fixes > _______________________________________________ > Users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected]/message/E7QTTECXLUD6LIEE36FBRJ3JSOQO27DP/ _______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/XMFRPECJQP325MBR3VSBUABWDU7Z2TIQ/
