Daniel P. Berrange wrote:
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 thiswill tell you what devices are part of the pool.
I would have said that creating VGs was outside the scope of what libvirt should be trying to do. Sounds like a real edge case that hardly any actual sys admins will exercise, since they can do a one-off VG creation when they install their server.
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, isthat 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.
Well possibly, but possibly also it's better to leave this up to device-dependent /etc/init.d scripts.
Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list