On Mon, Oct 29, 2007 at 02:50:43PM +0000, Richard W.M. Jones wrote:
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.
The use case I was thinking about s the context of iSCSI. The sysadmin
team managing the iSCSI storage volumes may provide you a target with
a couple of LUNS. You wish to put those LUNS into an LVM volume on the
host, thus enabling you to carve up the iSCSI storage locally to your
host without needing to roundtrip through the storage sysadmin team
every time. So being able to create LVM VGs is pretty critical if we
want this kind of remote management of the iSCSI storage.
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 -=|