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