Re: [libvirt] [PATCH v2] storage: vz storage pool support
[...]
>>
> 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.
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.
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.
[...]