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 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list