Re: [Libvir] PATCH: 0/16: Storage management APIs
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.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|