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.
> 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.
> 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)
> 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.
> 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
