[PATCH] storage: fix vstorage backend build

Nikolay Shirokovskiy nshirokovskiy at virtuozzo.com
Mon Jul 13 06:48:08 UTC 2020

On 10.07.2020 20:26, Daniel P. Berrangé wrote:
> On Fri, Jul 10, 2020 at 06:40:07PM +0200, Andrea Bolognani wrote:
>> On Fri, 2020-07-10 at 10:10 +0300, Nikolay Shirokovskiy wrote:
>>> On 09.07.2020 19:06, Andrea Bolognani wrote:
>>>> One thing at a time, though. First, how do we get the vstorage
>>>> commands included in the CentOS 7 container? What packages need to
>>>> be installed, and from what repository?
>>> The repo is http://repo.virtuozzo.com/vz/releases/7.0/x86_64/os
>>> vstorage binary is in vstorage-ctl package and vstorage-mount binary
>>> is in vstorage-client package.
>>> However vstorage binary is not used at all the driver. Also the openvz
>>> driver for example does not check for its binaries. Probably
>>> vstorage driver should be changed accordingly as binaries are not
>>> build requisites.
>> I'm not sure how the best way to handle the situation is. You should
>> look at what we do with qemu-img for inspiration.
>>>> As an aside, I'm still very confused by the vz/openvz dichotomy.
>>>> AFAICT, the latter can be (and in fact is) built unconditionally,
>>>> but the former requires the "Parallels SDK" packages to be installed:
>>>> baffingly enough, said SDK is obtained from the repository mentioned
>>>> above, which just so happens to include the string "openvz" twice in
>>>> its URL...
>>> Yeah, naming is confusing. Basically openvz manages system containers thru
>>> vzctl binary. Vz driver manages both VMs/containers thru single connection
>>> using prlsdk. And originally vz driver was called parallels driver but after
>>> company split we have to change the name. Also in the past prlsdk was only
>>> commercially available and now times changes and both vzctl and prlsdk are
>>> available under openvz name which is an umbrella for uncommercial projects.
>> Thanks for the explanation, but I'm afraid that even with it the
>> relationship between the various projects and products is only
>> marginally clearer to me O:-)
>> Anyway.
>> Starting from our existing CentOS 7 build environment, I've added
>>   [vz]
>>   baseurl=http://repo.virtuozzo.com/vz/releases/7.0/x86_64/os/
>>   enabled=1
>>   gpgcheck=1
>>   priority=90
>>   includepkgs=vstorage*,libvz*
>> to /etc/yum.repos.d/vz.repo and tried to install vstorage-client.
>> That failed with
>>   Error: Package: vstorage-libs-shared- (vz)
>>              Requires: libjson-c.so.2(libjson-c.so.2)(64bit)
>> which is surprising because I have the json-c package installed.
>> I think that's caused by a bug in your spec file - the name of the
>> library should not appear in parentheses - but I can't seem to find
>> the source package for vstorage-client under
>>   http://repo.virtuozzo.com/vz/releases/7.0/source/SRPMS/
> Yes, this dependancy is clearly broken, whcih is the reason why
> we're not using the URL you show above, and instead using the older
> release at:
>   https://download.openvz.org/virtuozzo/releases/openvz-7.0.11-235/x86_64/os/
> this URL is the last one that doesn't have the broken dependancies.
> I asked about this at the time but didn't get any response, so I guess
> it was buried in the email torrent and then i forgot to ping about it.
>   https://www.redhat.com/archives/libvir-list/2019-December/msg00437.html

Sorry, I missed that. We'll fix the issues.


More information about the libvir-list mailing list