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

[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.

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.
> 
[...]