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
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
pgpVQFUnElV3J.pgp
Description: PGP signature
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
