[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]