Re: [libvirt] [PATCH v2] storage: vz storage pool support
> 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?
Not sure what you're inferring by copy and paste - other than perhaps
having to decide for the vstorage backend which storage backend API's it
needs or should support.
The list of API's as I see from the path are:
+
+ .startPool = virStorageBackendVzStart,
+ .checkPool = virStorageBackendFileSystemCheck,
+ .stopPool = virStorageBackendFileSystemStop,
+ .findPoolSources = virStorageBackendVzfindPoolSources,
+ .buildPool = virStorageBackendFileSystemBuild,
+ .deletePool = virStorageBackendFileSystemDelete,
+ .refreshPool = virStorageBackendFileSystemRefresh,
+ .buildVol = virStorageBackendFileSystemVolBuild,
+ .buildVolFrom = virStorageBackendFileSystemVolBuildFrom,
+ .createVol = virStorageBackendFileSystemVolCreate,
+ .refreshVol = virStorageBackendFileSystemVolRefresh,
+ .deleteVol = virStorageBackendFileSystemVolDelete,
+ .resizeVol = virStorageBackendFileSystemVolResize,
+ .uploadVol = virStorageBackendVolUploadLocal,
+ .downloadVol = virStorageBackendVolDownloadLocal,
+ .wipeVol = virStorageBackendVolWipeLocal,
+
Other than startPool and findPoolSources, the code will reuse/call the
virStorageBackendFileSystem* API's - so the only copy/paste would be
copyrights, some #include's that would be required only for vstorage,
the VIR_FROM_THIS definition, VIR_LOG_INIT... Nothing any other backend
wouldn't have to do.
Although I do question "checkPool" - I would think for vstorage that
should check if the environment is "available" somehow *if* you want
pool autostart
Also for stopPool the code will essentially call unmount. So is that
"expected" for vstorage?
Going through each API callout is how you'll be able to tell me/us that
taking that path will work for the vstorage environment.
John