[PATCH] storage: fix vstorage backend build

Nikolay Shirokovskiy nshirokovskiy at virtuozzo.com
Tue Jul 14 06:44:15 UTC 2020

On 13.07.2020 12:16, Andrea Bolognani wrote:
> On Mon, 2020-07-13 at 11:52 +0300, Nikolay Shirokovskiy wrote:
>> On 13.07.2020 09:57, Nikolay Shirokovskiy wrote:
>>> On 10.07.2020 21:17, Andrea Bolognani wrote:
>>>> If you look at the list of packages through the provided "repoview"
>>>> files, the releases from the second repository contain many more:
>>>> additional categories include things like "Readykernel", Virtuozzo
>>>> High Availability" and, most interesting to us, "Virtuozzo Storage".
>>>> As mentioned in my previous message, some of these packages appear to
>>>> be released not under the (L)GPL but under a "Virtuozzo" license that
>>>> I haven't been able to find anywhere, and I'm not entirely sure is
>>>> actually open source.
>>> We have Virtuozzo product and part of it is available as open source
>>> from openvz.org repo. Virtuozzo Storage is not open source but it
>>> can be used with very limited storage size without license keys.
>>> I guess you would want to read license anyway before using Virtuozzo
>>> Storage packages in CI but I'm going to remove these packages
>>> requirements anyway as I wrote in reply to Andrea's message.
>> After giving it more thought I think it is useful to have vstorage
>> m4 script as it is. It is useful to detect vstorage-mount binary
>> path at build time. Although Virtuozzo Storage is not open source
>> and can not be build for distributions with different binary paths
>> by community it is a part of different Virtuozzo products and
>> theoretically speaking the path can be changed from product to product.
>> So it is useful to have path not hardcoded and not detected at runtime.
> If runtime detection is good enough for qemu-img, I don't see why it
> wouldn't be good enough for vstorage too.
>> Before we fix our repos please take a look at Virtuozzo license at [1]
>> (note there is different tabs and EULA tab).
>> [1] https://www.virtuozzo.com/legal.html
> Yeah, sorry, but I'm not going to put my name on a patch that results
> in our build environments suddenly including proprietary software.
> I'm already not a fan that happening based on principles alone, and I
> most certainly don't want to deal with any potential fallout from our
> container images violating the EULA or whatnot.

Ok, given all the license stuff and the fact we can just use runtime
binary detection let's go with this variant. I'll send the patch.


More information about the libvir-list mailing list