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

[Daniel P. Berrange]

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.

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  -=|