[Libvir] PATCH: 0/7 Implementation of storage APIs
Richard W.M. Jones
rjones at redhat.com
Mon Oct 29 14:50:43 UTC 2007
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 this
> will 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, 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.
Well possibly, but possibly also it's better to leave this up to
device-dependent /etc/init.d scripts.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
More information about the libvir-list