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

[Richard W.M. Jones]

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20071029/ded1cf15/attachment-0001.bin>