[libvirt] [PATCH v2] storage: vz storage pool support

[Maxim Nestratov]

08-Dec-16 15:17, John Ferlan пишет:

>
> On 12/08/2016 04:19 AM, Maxim Nestratov wrote:
>> 08-Dec-16 02:22, John Ferlan пишет:
>>
>>> [...]
>>>
>>>>> I see what you mean; however, IMO vstorage should be separate. Maybe
>>>>> there's another opinion out there, but since you're requiring
>>>>> "something" else to be installed in order to get the WITH_VSTORAGE
>>>>> to be
>>>>> set to 1, then a separate file is in order.
>>>>>
>>>>> Not sure they're comparable, but zfs has its own. Having separated
>>>>> vstorage reduces the chance that some day some incompatible logic is
>>>>> added/altered in the *fs.c (or vice versa).
>>>> Ok. I will try.
>>>>
>>>>> I think you should consider the *_fs.c code to be the "default" of
>>>>> sorts. That is default file/dir structure with netfs added in. The
>>>>> vstorage may just be some file system, but it's not something (yet) on
>>>>> "every" distribution.
>>>> I did not understand actually, what you mean  "be the "default" of
>>>> sorts."
>>>> As I have understood - what I need to do is to create backend_vstorage.c
>>>> with all create/delete/* functionality.
>>>>
>>> Sorry - I was trying to think of a better way to explain... The 'fs' and
>>> 'nfs' pool are default of sorts because one can "ls" (on UNIX/Linux) or
>>> "dir" (on Windows) and get a list of files.
>>>
>>> "ls" and "dir" are inherent to the OS, while in this case vstorage
>>> commands are installed separately.
>> Once you mounted your vstorage cluster to a local filesystem you can
>> also "ls" it. Thus, I can't see much difference from nfs here.
>>
> So if it's more like NFS, then how does one ensure that the local userid
> X is the same as the remote userid X? NFS has a root-squashing concept
> that results in numerous shall we say "interesting" issues.

Vstorage doesn't have users concept. Authentication is made by a password per node just once.
If authentication passes, a key is stored in /etc/vstorage/clusters/CLUSTER_NAME/auth_digest.key
Then, permissions are set to a mount point during mounting with -u USER -g GROUP -m  MODE options
provided to vstorage-mount command.

> Check out the virFileOpen*, virDirCreate, and virFileRemove...
>
> Also what about viFileIsShareFSType? And security_selinux.c code for
> NFS? If you use cscope, just search on NFS.
>
> In the virStorageBackendVzStart, I see:
>
>     VSTORAGE_MOUNT -c $pool.source.name $pool.target.path

This call certainly lacks user/group/mode parameters and should be fixed in the next series.

>
> where VSTORAGE_MOUNT is a build (configure.ac) definition that is the
> "Location or name of vstorage-mount program" which would only be set if
> the proper package was installed.
>
> In the virStorageBackendVzfindPoolSources, I see:
>
>     VSTORAGE discover
>
> which I assume generates some list of remote "services" (for lack of a
> better term) which can be used as/for pool.source.name in order to be
> well mounted by the VSTORAGE_MOUNT program.
>
> Compare that to NFS, which uses mount which is included in well every
> distro I can think of. That's a big difference. Also let's face it, NFS
> has been the essential de facto goto tool to access remote storage for a
> long time. Personally, I'd rather see the NFS code split out of the
> *_fs.c backend, but I don't have the desire/time to do it - so it stays
> as is.

To sum this up, you still think that copy and paste isn't a problem here and will create more value than do any harm, right?

Maxim

[snip]