Re: PATCH: 0/16: Storage management APIs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: danms@xxxxxxxxxx

Attachment: pgp3amSPEu42A.pgp
Description: PGP signature

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]