Hi!
Thanks for the review, I applied all of your corrections and will retest
the code and send a splitted version of the changes.
Also I'd like to ask you to provide a way to setup this storage
on our
CI system so that we can compile-test the new driver.
Well the easiest would be to use an Ubuntu VM, as Linbit provides a PPA
with packages
for DRBD and Linstor:
https://launchpad.net/~linbit/+archive/ubuntu/linbit-drbd9-stack
Add the PPA, install: drbd-dkms linstor-controller linstor-satellite
linstor-client
Add the node to the Linstor controller:
linstor node create <nodename> <ip>
Add a storage pool to the node:
linstor storage-pool create <type> <nodename> DfltStorPool <poolname>
Assuming you are only using 1 node for testing, you can create a
resource-group with 1 replica:
linstor resource-group create libvirtgrp --place-count 1
linstor volume-group create libvirtgrp
With that you can use libvirtgrp in the pool definition and should be ready
to go.
It might be simpler to skip DRBD and just use the Linstor storage layer,
then you don't need
the drbd kernel module. And the resource-group create would look like this:
linstor resource-group create libvirtgrp --place-count 1 -l storage
We'd also like to know if you are willing to continue maintaining
this
storage driver, so that it doesn't become abandonware right at commit
time.
Yeah sure, I'm willing to maintain it (or at least someone from Linbit will
in the future).
So if you use it like this, it means that the storage must be
accessible
via regular open() on the host system, is that so? (Asking because the
pool XML hints that the pool is accessed via a network protocol)
Linstor will create a block device(DRBD, LVM, ZFS, NVME) on the node, that
can be opened with open(),
but in the case of DRBD/NVME it is some kind of network storage so I wasn't
sure how this best fits in libvirt.
This should be defined via the build system once you detect where
the
program is located, to prevent PATH env variable from playing a role in
which program is actually used.
If it is ok I would also suggest to not let meson search for the linstor
client, as said it is a pure runtime dependency
and doesn't have any impact at compile time.
Best regards,
Rene