[PATCH] storage: fix vstorage backend build
nshirokovskiy at virtuozzo.com
Mon Jul 13 06:32:04 UTC 2020
On 10.07.2020 19:40, 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.
Yeah, qemu-img presence is not checked/required for build so I guess
I'll just fix vstorage driver to behave the same way.
>>> 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:-)
> Starting from our existing CentOS 7 build environment, I've added
> to /etc/yum.repos.d/vz.repo and tried to install vstorage-client.
> That failed with
> Error: Package: vstorage-libs-shared-220.127.116.11-1.vz7.x86_64 (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
> Moreover, when I try to get information about eg. vstorage-client,
> the output of 'yum info' contains
> License : Virtuozzo
> Is this an actual open source license that I can find anywhere?
> Until the packaging issue has been addressed and the license
> situation has been clarified, we can't move forward with building
> the vstorage driver as part of our CI pipeline.
So these issues will become irrelevant after the fix proposed above.
Nevertheless we fix our repos to have proper requirements of course.
> I did, however, reproduce the build failure you describe above and
> confirm that your patch fixes it in the process of writing this
> message, so
> Reviewed-by: Andrea Bolognani <abologna at redhat.com>
> to that.
More information about the libvir-list