On 08.12.2016 15:17, John Ferlan wrote: > > > 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. > > 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 > > 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. But netfs pool type is not only for NFS, it also can be used to provide cifs and FUSE glusterfs mounts. These three just as vstorage have very little difference from local filesystems from pool POV after they are mounted that's why I guess they implemented so tightly. > >>> When you create a vstorage "file" is that done via touch? or edit some >>> path or some other "common" OS command? Or is there a vstorage command >>> that needs to be used. If the former, then using the common >>> storage_backend API's should be possible. >> >> vstorage is just another "remote filesystem" type of distributed >> software defined storage. In terms of starting to use it, it doesn't >> differ from nfs - you should mount it and then you can use any POSIX >> calls to control files and directories resided on it. > > Here's a sample nfs pool xml I have - I changed the source/target path > and didn't define a host. > > <pool type='netfs'> > <name>nfs</name> > <capacity unit='bytes'>0</capacity> > <allocation unit='bytes'>0</allocation> > <available unit='bytes'>0</available> > <source> > <host name='localhost'/> > <dir path='/path/to/source'/> > <format type='nfs'/> > </source> > <target> > <path>/path/to/target</path> > <permissions> > <mode>0700</mode> > <owner>0</owner> > <group>0</group> > </permissions> > </target> > </pool> > > That is vastly different than what was in the cover: > > <pool type='vstorage'> > <name>VZ</name> > <uuid>5f45665b-66fa-4b18-84d1-248774cff3a1</uuid> > <capacity unit='bytes'>107374182400</capacity> > <allocation unit='bytes'>1441144832</allocation> > <available unit='bytes'>105933037568</available> > <source> > <name>vz7-vzstorage</name> > </source> > <target> > <path>/vzstorage_pool</path> > <permissions> > <mode>0700</mode> > <owner>0</owner> > <group>0</group> > </permissions> > </target> > </pool> > > What causes "vz7-vzstorage" to be defined? Something from the 'VSTORAGE' > command. I would think that is that essentially similar to how > glusterfs, rbd, or sheepdog uses a source <name> field. Note that each > of those include a <host name='$host' [port='#']/> definition, although > this vstorage XML doesn't. > > Thus it seems vzstorage is really not a "local" filesystem, correct? If > so, then should one really be allowing "local" things like chown, chmod, > etc. to be executed? What kind of "configuration and/or validation of > trust" takes place via vstorage provided tools in order to allow a user > on the local host to access the storage on the remote host. > > John >> >> Maxim >>> >>> John >>> >>> >>>>> Also I forgot to mention yesterday - you need to update the >>>>> docs/formatstorage.html.in at the very least and also the storage >>>>> driver >>>>> page docs/storage.html.in. >>>>> In addition there are storagepool tests (xml2xml) that would need to be >>>>> updated to validate the new storage pool type. The tests would "show" >>>>> how the pool XML would appear and validate whatever parsing has been >>>>> done. >>>> I know. Will fix. >>>> >>> [...] >> -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
