[Libvir] PATCH: 0/16: Storage management APIs
Dave Leskovec
dlesko at linux.vnet.ibm.com
Tue Feb 12 22:36:24 UTC 2008
Ok, I understand now. Thanks!
Daniel P. Berrange wrote:
> On Tue, Feb 12, 2008 at 02:13:59PM -0800, Dan Smith wrote:
>
>> DL> It would eliminate the need for mounts.
>>
>> Why?
>>
>> DL> Does it make more sense to integrate into the storage API design
>> DL> or leave the separate container specific mounts?
>>
>> From the perspective of a CIM provider, being able to correlate the
>> storage used by any set of domains (be them virtual machines or a
>> containers) to each other is important.
>>
>> Even if you can't provision* an overlay directory with libvirt (in the
>> way that this API lets you provision an LV), being able to model the
>> existence of one is important.
>>
>> I don't think this will change the XML of a container, but it will
>> give us a way to associate the path provided for a mount to a storage
>> pool.
>>
>> [*] provisioning in the containers case would be a recursive directory
>> copy of a template overlay directory, which is what Dan was saying
>> he didn't want to do
>>
>
> Yep, sorry I didn't make that clearer. There's 3 levels of increasing
> functionality we can do
>
> 1. Ability to create / view / associate the top level directory
> 2. Ability to populate the directory from some source
> 3. General purpose file management APIs
>
> Less is more. We can trivially do step 1, but I'll punt on the others
> unless we have clear compelling need from applications.
>
> Dan.
>
--
Best Regards,
Dave Leskovec
IBM Linux Technology Center
Open Virtualization
More information about the libvir-list
mailing list