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