[feature] Add support infiniband nuc and RDMA subsystem

[slavonnet]

Lets try ....

1; Add IB to Setup Host interface for assign static IP 2, Add IB network to claster for "Migration network" type select

3. Add support RDMA for:
   • Migrations (simple use rdma://)
   • nvme over fabric , nvme target, nvme-fc (simple modprobe and few cmds). Add blk dev to nameT and all host have access with latancy smaller than sas!
   • NFS over DRMA (simple flag/mount param)
   • iSer (iSCSI Over rdma) (simple modprobe)
4. Add option for emulate RDMA using rdma_rxe (software rdma. Simple add bind to any eth. thats all)
5. Add support for VMA (accelerate tcp/udp connect over rdma layer) and SPDK (many devices, drivers, agoritms and more) accelerators
6. Add qemu vhost rdma/ring for fast over VM internal fabrics support. Also OVN support RDMA backplain switch (vxlan and more)
7. Add support for RDMA Paravirtulisation device (assign RDMA dev to host/ring and every VM can emulate rdma nic)
8. Look to rdma multicast for locks, events, quorum and etc tasks
9. Loks to PCI assign device to any VM in ANY host!

few days work for half of this list and will get great profit!

P.S.

VDSM while RR jobs/cheksthis is most baddly (OSCAR prize!) architectute that i see.... Seriosly... sync tasks, big latancy between queue/tasks, error paths from begin in 80% times, reset hosts in 80% times bug in code or minor fails.... At most cases if vdsm not found hosted-engine its remount storages, restart services, restart hosts even other VM is UP. Any trys to migrate/pause/save/snapshot VMs? Any trys to detect errors from events, logs? Look to log! 90% work in vdsm is overhead and big latancy queue!

Change VDSSM ARCH to

• Ansamble small actions on events (async microservices RT) + conditions semaphore
• very small global state mashinwe (key-pair clustered db/memcached) + small base state actions (init, reset, set) (long time save async read db for all members)
• Events collectos + evemt bus subsriuptions for actions (async bus RT)=
• Long save services. Logs and system state persistent db for could start = All itens generate evemts to bus. All can subscribe for nedded events. Om any time service can check db for states (cold cache for members restarted or events RT state miss)/ But items must calculate states from event bus (hot cache RT). States used for aync barriers/mutesx/maintance/off/on logic. Simple, Fast, Reactive, COrrectForLargeUpScale/ You need only be cafuul for events storms

Please think about latancy, bottleneck, perfomance and TIME!

Thanks for watching and hacking! Beast regalst, best im, best you, with love and peace!

[sandrobonazzola]

@nirs @bennyz @ahadas can you please review?

[nirs]

Thanks @slavonnet but I don't think this issue is helpful. Adding infiniband support is not something that can be added in vdsm, this affects the entire system (engine, hosted engine, libvirt?, qemu?).

I suggest you start a discussion in the ovirt devel mailing list. The most important thing in this discussion why and how infiniband support is useful to the oVirt community.

The second part about vdsm architecture is not clear to me. Are you sure you understand what is the purpose of vdsm and how it operates? If will be more productive if you can identify specific issues in vdsm.

[mz-pdm]

As for RDMA migrations, AFAIK they had been considered by oVirt several years ago but were abandoned later. I think they are still not considered very reliable on the platform level.

[nirs]

We got no additional info from @slavonnet and I don't think the current issue is useful.

Feel free to reopen or create more specific and detailed issues instead.