[PATCH] storage: Linstor support

Rene Peinthor rene.peinthor at linbit.com
Tue Jan 19 13:01:01 UTC 2021


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20210119/7a2a5cc4/attachment-0001.htm>


More information about the libvir-list mailing list