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