Re: [Libvir] PATCH: 0/7 Implementation of storage APIs

On Mon, Oct 29, 2007 at 01:52:04PM +0000, Daniel P. Berrange wrote: > On Mon, Oct 29, 2007 at 12:03:34PM +0000, Richard W.M. Jones wrote: >> I was envisaging a much more straightforward config file: >> >> /etc/libvirt.conf ------------------- >> >> disk_storage_pools: [ "/var/lib/xen/images" ] >> lvm_volgroups: [ "/dev/MyXenImages" ] >> ------------------------------------- > That is not sufficient to describe all the metadata for the different > types of storage pool. To expand on that slightly. In the case of LVM volume groups. If the volume group already exists it may be sufficient to just provide the target path. There may be times though when the volgroup does not yet exist. In this scenario, the multiple <source dev='/dev/sda1'/> elements in the XMLdescription will be used as paths for the physical volumes and a new VG created from them. Similarly, when dumping the XML this will tell you what devices are part of the pool.

>> With this, you don't need to put storage logic into libvirtd. It can >> all be discovered on demand, just using the config file and the commands >> already included in storage_backend_*.c The upshot is that we don't >> need a daemon to manage storage pools, except in the remote case where >> it's just there to do things remotely. > To be honest even in the local case we need the daemon. The only reason > we previously get away without having a daemon when running locally, is > that the entire virt-manager app has run as root. Long term I think > pretty much all libvirt clients will be going via the daemon, whether > local or remote. THe more compelling reason for having the stateful driver in the daemon is that some storage needs to be activated manually & wont be explicitly available when a machine boots. This is what the autostart capability allows for - when the daemon starts will be automatically start all virtual networks, and all storage pools which need activation. This will typically mean logging into the iSCSI server, or mounting the disk on a path. There may be dependancies here - mounting the disk, may first require that the iSCSI server is activated, so we can't simply stick the disk mounts into /etc/fstab for auto mounting in that way.